小程序与跨端框架

• Fabric 渲染器与旧版 ShadowTree 的区别
• TurboModules 对 Native Modules 通信的性能改进
• Hermes 引擎与 JSI 在启动与运行时的价值

New Architecture 由三部分构成：Fabric 渲染器、TurboModules 与 JSI（JavaScript Interface），并由 Hermes 作为默认引擎。Fabric 将渲染管线重构为基于 C++ 的跨平台共享实现，支持同步渲染、优先级渲染（React 并发特性）与更精确的布局提交，解决了旧架构中 JS 与原生之间"bridge 批量异步传值"导致的首帧延迟和事件抖动。TurboModules 取代旧 NativeModules 体系，通过 JSI 实现方法级懒加载与强类型接口定义（codegen 自动生成），减少启动时全量加载原生模块的开销。Hermes 作为为 RN 预编译优化的 JS 引擎，配合字节码预编译与快照显著降低启动时间。

回答本题应先明确"三件套"各自的职责边界：Fabric 管渲染、TurboModules 管模块调用、Hermes 管 JS 执行，JSI 是连接 JS 与 C++ 的无桥接通道。再补充迁移要点：新架构要求原生模块按 TurboModule 规范改造、使用 codegen 生成接口、并处理 Fabric 下自定义 View 与事件系统的差异，体现从"理解概念"到"工程落地"的完整认知。

• 条件编译的注释语法与编译期裁剪原理
• easycom 的组件自动引入规则
• 小程序与 H5 在 API、DOM、布局上的差异处理

条件编译通过 #ifdef/#ifndef 注释块在编译期按平台宏（MP-WEIXIN、H5、APP-PLUS 等）裁剪代码，保证平台差异代码互不进入对方产物；easycom 约定组件目录即可在页面中直接使用而无需显式 import，编译器按需注入，减少了样板代码。小程序端与 H5 端的差异集中在三方面：一是 API 差异，小程序无完整 DOM/BOM，需用 uni API 封装层抹平；二是布局差异，小程序使用 rpx、H5 使用 rpx 转 rem/vw 的适配层；三是生命周期差异，onLoad/onShow 与 Vue 生命周期需映射。工程上通过条件编译、平台专用目录（platforms/）与统一 API 封装层治理差异。

本题考察对"一套代码多端编译"机制的理解：条件编译解决"代码级差异"，easycom 解决"组件级复用"，而运行时差异需靠框架抽象层与平台专属文件兜底。回答时应区分"编译期手段"与"运行时手段"，避免把所有差异都归结为条件编译。

• Taro 编译期将 React/Vue 代码转换为小程序 DSL
• 运行时适配层与虚拟 DOM 对齐
• 与 Uni-app 自研 DSL 路线的差异

Taro 3.x 采用"编译时转换 + 运行时适配"双轨方案：编译期利用 Babel/Webpack 将 React 或 Vue 组件编译为小程序原生结构，同时注入一个运行时适配层，把 React/Vue 的虚拟 DOM 与 setState 等机制映射到小程序的 setData 与组件树，从而实现"写 React，跑小程序"。与 Uni-app 相比，Taro 3 不复用自研 DSL，而是直接对齐 React/Vue 生态，开发者心智成本低；Uni-app 则维护自己的语法约定与 easycom 体系。Taro 的代价是编译与运行时适配复杂，需处理 setData 数据裁剪、事件绑定转换与生命周期对齐，且对 React 特性的支持存在滞后风险。

本题关键是理解"DSL 路线"的两种选择：要么自研语法（wepy/uni-app），要么复用一个已有框架（Taro 3 复用 React/Vue）。回答应包含编译器的输入输出、运行时适配层职责，以及该路线在多端产物一致性上的取舍，体现对跨端框架本质的把握。

• 元服务的形态与免安装分发
• ArkUI 声明式语法与状态管理
• 与前端工程（Web/小程序）的衔接方式

元服务（Atomic Service）是 HarmonyOS 中免安装、即点即用的轻量应用形态，通过卡片（Form）在桌面、负一屏等入口呈现，按需分发升级，适合工具类与高频轻量场景。ArkUI 是 HarmonyOS 的声明式 UI 框架，使用 ArkTS（TypeScript 超集）描述 UI，以状态驱动视图更新，提供组件化、动效与跨设备（手机、平板、车机）自适应能力。工程化应用上，前端团队可复用 TypeScript 技能栈，将业务逻辑抽离为平台无关的纯 TS 模块，UI 层用 ArkUI 重写；通过元服务卡片与主应用（HAP）配合实现"卡片触达 + 应用承接"的获客链路，并利用端云协同与一次开发多端部署（Stage 模型）减少多端维护成本。

本题考察对鸿蒙生态的工程认知：元服务解决"入口与分发"问题，ArkUI 解决"UI 开发"问题，二者结合构成跨端矩阵。回答时突出与前端技能的衔接点（ArkTS、声明式、状态驱动）与业务逻辑复用策略，展现工程化视角而非只罗列概念。

• 三棵树（Widget/Element/RenderObject）的关系与重建机制
• Impeller 的预编译着色器与抗锯齿改进
• 不同平台与版本下渲染后端的差异核查

Flutter 用三棵树协同驱动 UI：Widget 树是开发者声明的不可变配置；Element 树承载实例与生命周期，负责 Widget 与 RenderObject 的对应关系；RenderObject 树执行布局、绘制与命中测试。状态变化时 Flutter 只重建 Widget（廉价），通过 Element 复用尽量少的 RenderObject 完成更新。渲染后端方面，Skia 首次绘制时需即时编译着色器导致卡顿，Impeller 改为预编译（离线生成 Metal/GLSL 着色器），消除 jank，并提供更一致的抗锯齿与并发渲染支持。工程上需按目标平台核查：iOS 已默认 Impeller，Android 逐步开放、部分版本需显式启用，Web 与桌面端支持度仍在演进。

本题先答三棵树的分工与"Widget 重建≠重新渲染"的核心机制，再答 Impeller 相对 Skia 解决"着色器编译卡顿"的关键改进，最后强调"按平台与版本核查"的工程严谨性，避免给出跨平台一刀切的结论。

• wx.request 的 10 个并发上限约束
• 超限请求失败与超时的风险
• 请求队列化与优先级调度的实现

微信小程序中 wx.request 的同时进行请求数上限为 10（新版本 wx 支持 maxConcurrent 配置且不同版本限制不同，基础库较低时默认 10），超过上限的请求会被阻塞或失败，尤其在上传图片、批量数据请求等场景易触发超时与排队。工程上采用请求队列化治理：维护请求任务队列与并发计数器，按优先级（如核心接口优先、埋点降级）出队执行，每完成一个再从队列补充，同时配合超时控制、失败重试与取消机制，保证请求吞吐稳定。队列化还带来可观测性收益：统一埋点请求耗时、成功率与排队时长，便于定位瓶颈。

回答先给出并发上限事实，再说明超限的典型表现（请求挂起、超时、串行化导致首屏变慢），最后给出队列化设计（并发控制 + 优先级 + 重试）。把"限制"转化为"可控的调度策略"，是本题的得分点。

• 逻辑层（JSCore）与渲染层（WebView）分离
• setData 通过原生桥接传递数据
• 数据序列化开销与通信瓶颈

小程序将逻辑层与渲染层分离：逻辑层运行在独立的 JavaScript 引擎（iOS 为 JavaScriptCore，Android 为 V8）中，没有 DOM/BOM；渲染层由多个 WebView（每个页面一个）承载 WXML/WXSS。两层的 JS 环境完全隔离，交互数据通过 setData 经原生系统桥接传递，避免了 JS 逻辑直接操作 DOM 导致的渲染性能问题，也降低了 WebView 环境对逻辑代码的侵入。工程约束随之而来：setData 是"全量数据 diff 后序列化传递"，数据过大或过频会显著拖慢通信；逻辑层拿不到 DOM，需要事件转发与自定义组件机制补齐；多个 WebView 使全局状态同步成本上升。因此小程序编程强调"小步 setData、按需传递、减少非必要数据"。

本题核心是理解"为什么小程序要双线程"：WebView 单线程中 JS 执行会阻塞渲染，且逻辑代码暴露在 WebView 环境不安全。双线程用通信成本换取渲染稳定性与安全隔离，回答时把"架构优势"与"setData 约束"配套讲清，才能体现工程判断。

• 四类文件的职责划分与 JSON 配置
• WXML 数据绑定与事件系统
• 页面与组件生命周期的时序

小程序页面由四类文件组成：WXML 负责结构（类 HTML，支持数据绑定 {{}}、条件/列表渲染与事件绑定）；WXSS 负责样式（支持 rpx 与部分 CSS 特性）；JS 负责逻辑（Page 构造器注册数据与方法，运行于逻辑层）；JSON 负责配置（页面窗口、导航栏、组件引用等，不支持注释）。生命周期反映页面从创建到销毁的状态机：onLoad 在页面初次加载时执行且仅一次（可接收参数），onShow 每次页面显示时触发（含从后台回前台），onReady 在首次渲染完成时触发（此后可操作 canvas 等），onHide 在页面隐藏（如跳转其他页、切后台）时触发，onUnload 在页面销毁时触发。理解时序的意义在于：数据请求放 onLoad/onShow 需按需选择，避免重复拉取或漏拉取。

本题是基础题但考察完整性：四类文件各司其职（结构/样式/逻辑/配置），生命周期需区分"创建一次"与"每次显示"两类时机。回答时应结合 tab 切换、跳转返回等真实场景说明 onShow 与 onLoad 的触发差异。

• 各平台 API 命名与能力差异
• 平台特有的组件与审核规范
• 多端统一方案（uni-app/Taro）的适配策略

各平台小程序都采用"双线程 + 类 Vue 语法"的总体架构，但差异明显：API 命名不同（微信 wx.、支付宝 my.、抖音 tt.、百度 swan.），部分能力为平台独有（支付宝的芝麻信用与支付、抖音的短视频挂载与直播、百度的智能小程序 AI 能力）；组件集与样式单位有差异（rpx 换算、组件属性命名）；审核与运营规范不同（类目资质、虚拟支付限制）。多端开发通常基于 uni-app/Taro 等跨端框架，把平台差异收敛到框架的条件编译与 API 适配层，业务代码尽量只调用框架统一 API；对平台独占能力通过条件编译或原生插件隔离，并在 UI 层按平台微调，避免"一套样式通吃"。

回答分两层：先讲清各平台的本质差异（API、组件、规范三个维度），再给出工程策略（框架收敛 + 条件编译 + 平台插件隔离）。不要只罗列"哪里不一样"，而要落到"多端项目怎么组织"。

• behavior 的合并规则与优先级
• mixin 的命名冲突与隐式依赖问题
• 组合优于继承的替代方案

behavior 是小程序组件间共享代码的机制，支持 properties、data、methods、生命周期与 observer 的合并，同名属性按"组件自身 > 后引入的 behavior > 先引入的 behavior > 默认值"的优先级覆盖，生命周期则全部按序执行。它与前端 mixin 相似：都存在隐式依赖、命名冲突与"代码来源不透明"的问题，调试时难以定位属性来自哪个 behavior。现代取舍上：优先用组合替代继承——把可复用逻辑抽成独立组件或自定义 hook（Composables）注入；behavior 仅用于跨组件共享的纯配置（如通用属性声明、公共样式或埋点方法），并保持命名前缀约定与最小职责；对复杂依赖链使用显式注入或服务层，避免多层 behavior 叠加。

本题考察对"共享逻辑复用"两种路线的权衡：mixin/behavior 便捷但牺牲可追踪性。回答应给出 behavior 的合并优先级事实，再结合现代前端"组合优于继承"的实践提出取舍建议，避免单纯褒贬。

• 组件 properties/data 与 observer 的隔离机制
• 样式隔离（styleIsolation）与事件冒泡控制
• 跨平台复用的边界：平台 API、原生组件差异

小程序自定义组件通过四重隔离保证独立性：数据隔离——组件维护自己的 data，外部通过 properties 单向传入，内部状态不污染页面；样式隔离——默认 styleIsolation: isolated 使组件内样式不影响页面、页面样式也不进入组件，可通过 apply-shared/shared 精确放开；事件隔离——组件内事件默认不冒泡到页面，需通过 triggerEvent 显式抛出自定义事件，页面用 bind:xxx 接收；节点隔离——组件内外通过 relations 建立显式关系。跨平台复用的边界在于：纯 UI 与纯逻辑组件（props 驱动、事件输出）可以跨平台复用；一旦依赖平台 API（支付、定位、系统能力）、平台专属组件（如微信的原生表单组件、抖音的短视频组件）或平台样式特性（rpx 在各端换算差异），就必须用条件编译或平台实现隔离，复用边界即"是否触及平台专属能力"。

本题前半考察组件封装规范（隔离的四个维度），后半考察架构判断（复用边界）。回答关键是"以平台能力为分界"：能参数化的抽象可复用，绑定平台能力的必须分叉。

• Lynx 的线程模型与渲染架构
• 与 Flutter 自绘渲染的差异
• 与 Web 生态兼容性与性能的权衡

Lynx 是字节跳动的跨端框架，核心特点是把业务逻辑放在独立的 JS 线程执行（类似小程序双线程），渲染由原生引擎完成，并支持 Web 环境兼容运行。它提供 React-like（Lynx React）与 Vue-like（Lynx Vue）两套前端开发体验，通过"共享 UI 组件 + 原生渲染"在性能与开发效率间取平衡。与 Flutter 相比：Flutter 自绘所有像素（Skia/Impeller），跨平台一致性最强但与 Web 生态割裂，需用 Dart；Lynx 用前端 DSL，能复用 Web 技能与部分生态，但一致性依赖原生组件的对齐程度。与 Web 相比：Lynx 用原生渲染换取性能与流畅度，代价是 DOM/CSS 能力子集化，复杂布局与动效需使用受限能力。工程取舍：重性能、深交互、团队有前端背景时选 Lynx 类方案；追求极致一致性与生态独立性选 Flutter；标准化与全能力优先则选 Web。

本题是方案对比题，应建立统一的比较维度：渲染方式（自绘 vs 原生组件 vs WebView）、开发语言（Dart vs JS/TS）、生态兼容、性能与包体积，再逐维度对比得出结论，避免泛泛而谈。

• uni-app x 自研编译器与原生渲染
• Taro 3 复用 React/Vue 生态的路线
• DSL 生态、性能与团队技能的权衡

uni-app x 是 uni-app 的下一代版本，不再依赖 WebView 或小程序运行时，而是把类 Vue 的 DSL 直接编译为各端原生 UI（App 端编译为 Kotlin/Swift，小程序端编译为原生小程序），追求原生性能，代价是需要维护自研编译器且部分 Vue 生态依赖需特殊适配。Taro 3.x 则复用 React/Vue 源码生态，编译加运行时适配到小程序与 H5，开发者可全量使用框架能力，代价是运行时适配层的性能损耗与小程序 setData 瓶颈。取舍上：追求原生渲染性能与确定性（如 App 为主、交互重的项目）倾向 uni-app x；看重生态完整度、团队 React/Vue 熟练度与快速交付则选 Taro 3；还需评估社区活跃度、周边工具链与长期维护成本。

对比类问题的回答框架是"两条路线各自的机制 → 优势 → 代价 → 适用场景"。uni-app x 与 Taro 3 的核心差异在"自研编译到原生"与"复用生态 + 运行时适配"，工程选型最终回到性能、生态、团队三项权重。

• Taro 4 对 React 19 新特性的支持
• 编译时优化（如 tree-shaking、预构建）
• 对包体积与运行时性能的影响

Taro 4 升级了对 React 19 的适配：支持 React 19 的并发渲染相关能力、新的 hooks 行为与编译产物格式，通过编译器将 React 19 的调度语义映射到小程序运行时，并优化了事件系统与 setData 的同步策略。编译时优化方面，Taro 4 重构了基于 Rspack 的构建链路，提供更细粒度的 tree-shaking、依赖预构建与产物分包能力，可显著减小小程序包体积、缩短构建时间。工程价值在于：团队可以更早使用 React 19 的生态与性能改进，同时通过编译期手段而非运行时 hack 解决跨端兼容问题，降低维护成本，提升多端产物的一致性与构建效率。

本题考察对框架版本演进的跟踪能力：回答应落到"React 19 的新语义如何被翻译到小程序"这一本质，以及"编译时优化如何替代运行时妥协"，并说明对构建效率与包体积的实际收益。

• wepy 类 Vue 语法的编译目标与维护状态
• Taro 3 对 React/Vue 生态的编译适配
• uni-app 多端产物与平台新特性跟进速度

三条路线对小程序编译目标的兼容性不同：wepy 是最早的类 Vue 小程序框架，编译目标仅微信小程序，功能深度绑定早期微信特性，目前已基本停止维护，新项目不建议采用；Taro 3 以"复用 React/Vue 生态"为目标，编译器覆盖小程序、H5 与 RN，对平台新特性（如 Skyline、新组件）的跟进依赖框架发版节奏，社区活跃但需关注版本升级成本；uni-app 直接面向多端（小程序、H5、App），编译器与运行时适配层由官方统一维护，对微信新特性跟进较快，但自定义程度受限、大版本迁移有一定成本。工程取舍上：单平台且求稳可选原生或 uni-app；多端且团队 React 背景选 Taro；遗留 wepy 项目需评估迁移成本与停止维护风险。

本题考察对历史路线与现状的判断：兼容性不仅是"能不能编译"，还包括新特性跟进速度、维护状态与迁移成本。回答按"框架现状 + 特性跟进 + 适用场景"结构展开即可。

• Skyline 的原生渲染与双线程模型
• 更贴近 W3C 标准的布局与样式能力
• 提升滚动、动画与首屏性能的机制

Skyline 是微信小程序新一代渲染引擎，不再依赖 WebView，而是基于自研原生渲染管线实现双线程模型：逻辑层与渲染层分离，渲染层由原生 UI 引擎接管，视图树与布局直接在原生侧完成。它更贴近 W3C 标准，支持更多 CSS 特性（如部分 grid/flex 增强、overflow、sticky 等）与更完整的动画能力，减少"WebView 语义折损"。工程价值：首屏更快（免去 WebView 初始化与 HTML/CSS 解析）、滚动与手势更流畅（原生列表滚动）、动效性能更高（动画在渲染线程执行），同时通过 WXS/渲染层脚本进一步降低通信成本。代价是部分旧特性（如 web-view 内嵌、部分组件）与 WebView 模式存在差异，需按页面能力矩阵选择渲染模式。

回答应抓住"原生渲染替代 WebView"这一本质，以及"更贴近 W3C 标准"带来的能力提升，最后落到首屏、滚动、动画三类性能收益与迁移注意点。

• 云开发的免运维服务形态
• 云函数（Node 运行时）与权限模型
• 云数据库/云存储的安全规则与配额

云开发（CloudBase/TCB）为小程序提供云函数、云数据库、云存储与云调用等一体化能力，免去自建服务器：云函数运行在 Node.js 环境，封装业务逻辑与第三方接口调用，通过 wx.cloud.callFunction 触发，天然解决"密钥不能放前端"的问题；云数据库是文档型数据库，支持在小程序端直接读写，安全规则（权限标签）控制访问；云存储用于文件上传下载，配合安全规则与 CDN 分发。工程注意点：云函数冷启动影响体验，需合理拆分函数粒度与预留并发；数据库读写要设计索引与分页，避免超时与配额超限；安全规则必须显式配置，默认不要开放写权限；环境（dev/prod）隔离与本地联调工具链需纳入流程。

本题考察对 BaaS 形态的理解：核心是"前端直连数据库 + 云函数兜底敏感逻辑"的架构模式，以及安全规则、配额、冷启动三类工程红线。

• 京东小程序的电商交易能力
• QQ 小程序的社交与流量入口能力
• 平台接入时的适配与合规注意点

京东小程序依托电商生态，提供交易闭环能力（商品、订单、支付、物流）、营销组件（秒杀、拼购）与京麦数据能力，适合电商工具与商家运营类场景；QQ 小程序依托 QQ 社交关系链与群聊场景，具备群应用、QQ 号登录、好友分享与基于 QQ 的用户画像能力，适合社交裂变与内容互动类应用。接入注意点：各平台的开放能力、API 命名与审核类目不同，需按平台申请权限（如支付资质、敏感接口）；跨端框架（uni-app/Taro）对京东/QQ 的支持完整度不一，平台特有能力需条件编译隔离；遵循各平台的数据合规与虚拟支付规范，避免同一套逻辑因平台规则差异导致审核失败。

回答先分别概括两平台的差异化能力（京东=交易闭环，QQ=社交裂变），再落到多端工程的三类注意点：权限申请、框架支持度、平台合规。

• 旧 Bridge 的批量异步通信局限
• JSI 提供 JS 与 C++ 直接互调
• Fabric 的同步渲染与并发能力

旧架构的核心是 Bridge：JS 与原生通过 JSON 序列化消息异步批量通信，导致调用延迟不可控、方法全量加载、无法同步读取返回值，动画与手势等高频场景出现卡顿。新架构以 JSI 取代 Bridge：JSI 是 C++ 层接口，让 JS 引擎能直接持有并调用 C++ 宿主对象，无序列化开销、支持同步调用，TurboModules 借此实现按需懒加载；Fabric 渲染器在 C++ 侧统一维护 UI 树，支持同步布局提交与按优先级调度渲染，配合 React 并发特性减少首帧阻塞。Hermes 引擎则通过预编译字节码与内存优化降低启动与运行开销，与新架构协同提升整体性能。

本题是"新旧对比"题：先讲 Bridge 的三大瓶颈（序列化、全量加载、异步不可控），再对应讲 JSI/TurboModules/Fabric 如何逐一解决，Hermes 作为执行引擎补足启动性能，形成完整因果链。

• Skia 声明式渲染 API 与 GPU 加速
• 与 RN 原生视图体系的互补
• 图表、动画等场景的应用边界

@shopify/react-native-skia 把 Skia 图形库以声明式组件的形式引入 React Native，用 React 描述绘制指令（Canvas、Path、Shader、Image 等），由原生侧 GPU 执行渲染，摆脱 JS 层逐帧绘制与 View 体系的开销。工程价值：一是性能，复杂图形（图表、粒子、富文本排版）以 GPU 指令批处理渲染，避免大量原生 View 的创建与协调成本；二是与 RN 生态集成自然，可用 React 状态驱动重绘，配合 Reanimated 在 UI 线程驱动动画；三是跨端一致性，同一套绘制代码在 iOS/Android 表现一致。边界：不适合作为通用 UI 布局框架，适用于数据可视化、绘图白板、滤镜、游戏 HUD 等图形密集场景，且需注意内存与纹理管理。

回答抓住"声明式绘制 + GPU 渲染"的本质，说明它为什么比 View 堆叠高性能，再给出典型场景与边界，展示对"渲染管线选型"的理解。

• web-view 承载 H5 的能力边界与限制
• Hybrid H5 在 App 内的桥接与更新优势
• 业务形态与性能的匹配

小程序 web-view 用于在小程序内嵌入 H5 页面：优点是可复用已有 H5 业务、免审核迭代快；限制包括域名需配置业务域名白名单、不支持大部分小程序原生能力（支付、部分硬件）、跳转受限、web-view 与小程序页面通信只能通过 postMessage 且时机受限。Hybrid H5（App 内 WebView + JSBridge）则把 H5 作为 App 内一等公民：通过桥接层调用原生能力（支付、定位、推送），配合离线包与增量更新获得接近原生的加载体验，适合内容重、迭代快的业务。取舍依据：已有 H5 资产与运营灵活性优先选 Hybrid；需要小程序生态流量、审核合规与原生组件体验优先选小程序，web-view 仅作为"长尾页面兜底"嵌入，避免核心交易链路依赖它。

本题考察"容器选型"思维：web-view 与 Hybrid 都是"H5 进容器"，差异在容器能力、桥接深度与更新机制。回答按"能力矩阵 + 场景匹配"给出结论，而非单一答案。

• Lynx 逻辑线程与 UI 线程的分离
• Web 端重叠渲染（Overlap Rendering）的原理
• 一套代码在原生与 Web 双端的一致性保障

Lynx 双线程架构把业务 JS 放在独立逻辑线程，UI 构建与渲染由主线程的原生引擎执行，避免 JS 长时间执行阻塞渲染；同时允许在主线程运行轻量脚本（如手势处理）保证交互响应。Web 重叠渲染（Overlap Rendering）指 Lynx 在 Web 端将同一套 Lynx 页面用 WebView 的 DOM 渲染，使 LYNX 代码可以"一次编写、原生与 Web 双端运行"，Web 端复现与原生端一致的组件树与样式。工程价值：开发者用 React/Vue 心智编写，运行时由 Lynx 引擎接管原生端、WebView 接管 Web 端，业务逻辑与 UI 描述保持同一份；需注意双端能力差异（如部分原生组件无 Web 等价物）需在能力矩阵中声明降级。

回答先解释双线程如何保证流畅（逻辑与渲染分离、主线程轻量脚本），再解释重叠渲染如何保证 Web 端一致（同一组件树映射到 DOM），最后落到双端一致性治理的工程约束。

• JSI/Bridge/JSBridge 三类桥接通道
• 协议设计（方法注册、参数校验、回调与错误码）
• 权限与安全边界

跨端框架调用 Native 能力有三类通道：React Native 的 JSI/TurboModules（C++ 直调）、Cordova/Capacitor 式插件桥（JS 与原生通过约定协议通信）、Hybrid H5 的 JSBridge（URL Scheme 或注入 API）。桥接协议设计要点：统一封装 NativeModule/Plugin 注册表，方法名与参数采用版本化 JSON 协议；入参做类型与长度校验，返回值区分业务数据与错误码；回调（Callback/Promise/Event）区分"一次性响应"与"持续事件流"（如定位变化、传感器），后者用事件订阅机制避免泄漏；所有能力在声明时标注所需权限，由框架统一鉴权与降级提示。安全上遵循最小权限：前端只能调用白名单能力，敏感操作由 Native 侧二次确认，禁止把系统级接口直接暴露给 JS。

回答应从"通道选型 → 协议设计 → 安全治理"三层展开，突出可维护性关键点（版本化、错误码、事件订阅），体现对桥接层作为"平台能力边界"的理解。

• 渲染性能与交互流畅度差异
• 原生能力覆盖度与体验一致性
• 场景匹配与成本评估

跨端框架以"一套代码多端运行"换取开发效率，代价通常体现为三方面：渲染链路多一层抽象（自绘或原生组件映射），复杂动画与长列表可能不如原生；平台能力覆盖滞后于原生 SDK 发版，新系统特性需等待框架适配；生态依赖框架升级，调试与性能剖析工具链受限。取舍原则：内容型、表单型、数据展示型应用（电商、资讯、工具）跨端收益高，性能差异可被接受；高帧率游戏、音视频编辑、系统级集成（手表、车机）等对性能与平台特性敏感的场景应原生实现或混合架构（核心原生 + 业务跨端）。工程上通过性能基准（启动、首帧、滚动帧率、内存）在选型阶段量化对比，用"性能预算"约束方案选择。

本题考察架构决策能力：先讲跨端的通用代价（渲染抽象、能力滞后、工具链），再给"内容型适合、性能敏感型原生"的判断标准，最后落到用基准测试数据驱动决策。

• 端、平台、框架三个维度的适配层次
• 编译期与运行期的适配手段
• 一致性保障：能力矩阵、视觉基准、自动化验证

适配可拆为三个维度：跨端（小程序/H5/App/桌面）需处理容器能力差异（DOM 缺失、setData、JSBridge）；跨平台（iOS/Android/Windows）需处理系统行为差异（键盘、安全区、字体、权限弹窗）；跨框架（React/Vue/原生）需处理 DSL 差异。策略上分层：编译期用条件编译、平台目录、多端组件映射裁剪差异；运行期用统一 API 封装、能力探测（feature detection）与降级实现；UI 层建立设计 Token 与跨端组件库保证视觉一致。保证一致性要靠机制而非自觉：维护"能力矩阵"文档与运行时能力检测结果对齐；建立视觉回归与交互基线测试（截图 diff + 自动化用例）；发布前用真实设备矩阵执行端到端验收。

回答先厘清三个维度各自的差异来源，再给"编译期/运行期/UI 层"三层适配策略，最后落到能力矩阵与自动化验证这两项一致性治理手段。

• 日志分级、埋点与链路追踪
• 设备/系统/网络维度的问题画像
• 远程诊断与灰度定位流程

跨端可观测性需四层建设：日志层——统一日志 SDK 分级采集（debug/info/warn/error），附带上下文快照（页面栈、网络状态、内存）；指标层——启动时长、首帧、JS 错误率、崩溃率、卡顿率等核心指标按端/平台/版本聚合；链路层——请求 ID 贯穿前端到后端，关联用户行为与异常；诊断层——支持远程下发日志级别、抓取现场（调用栈、原生日志）与灰度切换 SDK 版本。根因区分靠维度标签：设备（机型、OS 版本、内存）、系统（API 行为差异、权限）、网络（弱网、DNS、运营商）分别打点，用"同版本不同设备/同设备不同网络"的对比分析定位：仅特定机型崩溃→设备/系统侧；弱网下超时集中→网络侧；全端同现→业务代码。配合崩溃符号化、内存快照与网络面板即可闭环。

回答按"日志/指标/链路/诊断"四层建设展开，再给出根因定位方法论：以维度化标签做对比分析，把设备、系统、网络三类原因区分开。

• RN 渲染与原生组件的边界
• 平台差异（布局、键盘、权限、字体）
• 适用场景与混合架构

RN 的工程边界由"组件与 API 的覆盖度"决定：通用 UI 组件（View/Text/ScrollView）跨端一致，但深度系统集成（复杂手势、系统级 UI、原生地图/视频、Core ML/ML Kit 等）需要自定义原生模块补齐，且 iOS 与 Android 的系统行为（键盘避让、权限弹窗、字体度量、滚动惯性）存在固有差异，需平台代码分别处理。现代应用实践：用 RN 承载高频迭代的业务界面（信息流、表单、运营页），把性能敏感或强平台依赖的模块（视频播放、图像处理、推送 SDK）下沉为原生模块，形成"原生壳 + RN 业务 + 原生组件补位"的混合架构；同时利用新架构（Fabric/TurboModules）与 Hermes 改善启动与列表性能。边界判断标准：若业务 80% 以上可用 RN 组件表达且对原生新特性无强依赖，则收益显著。

回答核心是"边界即能力覆盖度"：通用 UI 归 RN、系统深度能力归原生，并明确 iOS/Android 行为差异需平台代码治理，最后给出混合架构与边界判断标准。

• Expo 托管工作流与开发工具链
• Expo Modules 与热更新（EAS Update）
• 受控边界：原生代码自由度

Expo 是 RN 的增强框架，工程价值体现在四方面：开箱即用的开发环境（Expo Go 真机预览、Web 支持、一键创建项目），消除配置地狱；预构建的原生能力库（相机、定位、推送、生物识别等）通过 Expo SDK 统一版本管理；EAS（Expo Application Services）提供云构建、云签名与 OTA 热更新，简化 CI/CD 与发版流程；Config Plugin 允许以声明式方式配置原生工程，兼顾部分原生定制需求。边界：纯 Expo Go 工作流无法使用自定义原生代码，需要"开发构建（Development Builds）+ prebuild 生成原生工程"来扩展；团队若以深度原生定制为核心诉求，直接使用裸 RN 更合适。现代推荐路径：Expo 起步 + prebuild + EAS 发布，按需进入原生领域。

回答抓住 Expo 的本质"管理原生复杂度"：用托管服务与声明式配置换取开发效率，边界在原生自由度，并用"prebuild + 开发构建"说明如何突破边界。

• 自绘渲染的跨端一致性与性能
• 各平台插件生态与能力覆盖
• Web/Desktop 的适配差异

Flutter 用自绘引擎（Impeller/Skia）在 iOS/Android 上实现高度一致的渲染表现，动效与排版可像素级一致，移动端体验成熟；Web 端通过 CanvasKit/HTML 两种渲染器运行，CanvasKit 保证一致性但首载体积较大、文本可访问性受限；Desktop（Windows/macOS/Linux）支持较完善，可调用各桌面平台能力（系统菜单、托盘、文件关联）。适配要点：移动端关注 iOS 键盘避让、手势冲突与字体差异；Web 端关注 SEO、可访问性与首屏体积；桌面端关注窗口管理、多显示器与系统集成；平台插件需用 federated plugins 模式按平台实现，能力缺口用 MethodChannel 自建补足。

回答按"一致性收益 + 每平台差异"展开：先讲自绘带来的跨端一致，再分别讲移动、Web、桌面三类平台的适配要点与插件边界。

• Tauri 的 WebView + Rust 架构与包体积优势
• 命令（invoke）通信与权限控制
• 相比 Electron 的生态与成熟度边界

Tauri 用系统 WebView（Windows WebView2、macOS WKWebView、Linux WebKitGTK）承载前端，Rust 作为后端处理文件、系统 API 与高性能计算，前端通过 invoke 调用 Rust 命令。优势：安装包极小（几 MB 到十几 MB，不含 Chromium）、内存占用低、Rust 侧性能与安全性强、支持多窗口与系统集成。边界：WebView 兼容性取决于系统版本（旧 Windows 需安装 WebView2 运行时），渲染表现不如 Electron 内置 Chromium 统一；Rust 学习成本与开发迭代速度弱于 Node；插件生态与文档规模小于 Electron。工程上适合对包体积、资源占用敏感且团队能接受 Rust 的工具型、轻量桌面应用；重渲染能力、深度 Chrome 特性的应用仍选 Electron。

回答先讲架构（系统 WebView + Rust 命令通道），再讲优势（体积、内存、安全）与边界（WebView 差异、生态、团队），最后落到场景选型。

• Capacitor 作为 Web 到原生桥接层
• 插件系统与原生工程管理
• 与 Cordova 的差异及 Web 优先策略

Capacitor 是 Ionic 的官方原生运行时：Web 代码（HTML/JS/CSS 或框架）打包进原生壳（iOS 用 WKWebView、Android 用 WebView），通过 Capacitor Bridge 调用原生能力。核心机制：标准 Web 项目 + 原生壳，前端代码与原生工程通过 npm 依赖管理，插件（Camera、Push、Filesystem 等）以统一 JS API 暴露原生实现；原生工程由 Capacitor 生成并允许手工扩展，运行原生代码（如 health 数据）可写独立插件。与 Cordova 相比：Capacitor 现代化依赖管理（npm 而非插件仓库）、支持任意前端框架、原生代码可自由混写、通过本地服务器/离线资源加载更贴近现代 Web 开发。工程价值：保持"Web 优先"，同一代码库同时交付 Web 与移动端，迭代速度快，适合内容与管理型应用；深度系统集成或极致性能场景仍需原生或 RN/Flutter。

回答抓住 Capacitor 的本质"给 Web 应用加原生能力桥"，说明插件体系与原生工程可扩展性，再与 Cordova 对比突出其 Web 优先与现代工具链优势。

• Cordova 的插件与依赖管理方式
• 原生混编与构建链路的差异
• 项目迁移 Capacitor 的路径

Cordova 是历史最久的 Hybrid 框架，其工程短板：插件体系为独立仓库与 CLI 安装，依赖关系脆弱、与现代 npm 生态脱节；原生代码需通过插件封装，直接混编体验差；基于早期 WebView 的渲染与调试能力弱于现代 WKWebView 特性；构建配置（config.xml、hooks）较繁琐。Capacitor 以 npm 管理插件、原生工程即普通 Xcode/Android 工程、桥接层更薄，因此社区与官方都推荐新项目使用 Capacitor。现状：Cordova 进入维护模式，官方不再积极演进，遗留项目建议渐进迁移：先确认插件是否有 Capacitor 等价物，按"桥接层替换 + 原生代码抽离"两步走，保留业务 Web 代码不变，降低迁移风险。

本题考察对技术代际的判断：从插件生态、原生混编、WebView 能力三个维度对比 Cordova 与 Capacitor，并给出务实的迁移路径，避免"非黑即白"。

• uni-app 对 Vue 语法的编译支持
• 三端运行时的差异（DOM、路由、生命周期）
• 工程组织与条件编译实践

uni-app 让 Vue 开发者用同一套代码编译到 H5、小程序与 App，工程价值在于技能复用与交付速度：Vue 语法、组件模型与状态管理（Vuex/Pinia）一致，团队无需学习多套 DSL。三端差异：H5 有完整 DOM/BOM，可直用 Web API 与 CSS 特性；小程序无 DOM、样式与组件受限（rpx、无部分选择器）；App 端（uni-app 编译为原生渲染或 WebView 两种模式）需关注 JSBridge 与原生能力调用。注意点：生命周期对齐（onLoad/onShow 与 Vue mounted 的映射）、路由与页面栈差异、条件编译隔离平台代码、以及使用 uni 封装 API 而非直接操作 DOM；对平台特有功能（分享、支付）按端实现。实践上建议将业务逻辑与平台差异解耦，UI 组件优先 uni-ui 等跨端组件库。

回答先给价值（一套代码、技能复用），再按三端差异展开，最后落到生命周期、API 封装与条件编译三项工程实践，体现可操作性。

• Taro 3 的运行时适配架构（React reconciler）
• 三端能力差异与降级策略
• 依赖选型与版本对齐实践

Taro 3+ 通过在编译期把 React 组件翻译为目标端结构，并在运行时注入适配层（自定义 reconciler）将 React 渲染同步到小程序 setData、H5 DOM 或 RN 原生组件，开发者使用标准 React 编写。工程实践要点：组件与依赖必须选择"跨端兼容"的版本（避免依赖 DOM API 的库，如部分 UI 库、window 操作），用条件编译隔离平台代码；样式尽量使用各端都支持的 CSS 子集（flex 布局、无浏览器私有特性）；小程序端注意 setData 数据量控制与组件通信（redux/recoil 状态统一管理）；路由与页面配置按端声明；发布前用各端真实环境跑全量回归，重点验证生命周期与事件差异。长期维护需跟随 Taro 发版节奏，评估 React 版本升级对适配层的影响。

回答先讲"reconciler 适配"的核心机制，再落实践：依赖选型、条件编译、setData 治理、多端回归与版本升级管理。

• WePY 的类 Vue 语法与编译模型
• 维护停滞与平台特性跟进问题
• 迁移到 Taro/uni-app 的路径

WePY 是最早的"类 Vue"小程序框架之一，用类 Vue 的单文件组件语法（script 的类结构、computed、methods）编译为微信小程序代码，曾广受欢迎。其工程特点：编译目标以微信小程序为主，对 Vue 语法是"近似实现"而非完整支持（无完整响应式系统、指令支持有限），组件体系（wepy component/mixin）与 Vue 现代实践存在差异。现状：项目长期维护停滞，对微信新特性（Skyline、新组件、新版基础库能力）跟进迟缓，新项目不建议选用。遗留项目应对：评估业务体量与平台依赖，渐进迁移到 Taro 3 或 uni-app——先平移页面结构与数据逻辑，重写组件与样式，用条件编译兼容过渡期双端并存，最终下线 WePY 构建链路。

回答先客观说明 WePY 的历史价值与语法特点（类 Vue 但非完整 Vue），再明确指出维护现状，最后给出可执行的迁移路径，体现务实态度。

• 原生模块的注册与 JS 接口设计
• 多平台实现与桥接规范
• 异步回调、线程与资源管理

原生模块扩展的工程实践分四步：接口设计——JS 侧定义类型化的 Promise 接口与参数校验，命名遵循平台习惯（如 RN 的 NativeModules、Flutter 的 MethodChannel、Cordova 的 plugin）；平台实现——iOS/Android/Web 分别实现同一协议，返回统一错误码结构（code/message/data），避免各端错误语义漂移；桥接细节——耗时操作必须放后台线程、回调回主线程，避免阻塞 UI；长生命周期对象（连接、流）用资源句柄加显式 release 管理，防止泄漏。工程保障：用自动化测试对各端模块做一致性验证（同一输入断言同一输出），文档化模块能力矩阵与版本兼容声明；模块发布走独立版本号，与框架主版本解耦。

回答按"接口设计 → 多平台实现 → 桥接与资源 → 测试与版本"的工程链路组织，重点突出错误码统一、线程模型与资源释放三个易错点。

• 字节码预编译与 AOT 执行
• 启动时无 JIT 编译开销
• 内存占用与快照优化

Hermes 是专为移动端优化的 JS 引擎，其启动性能优化机制：一是字节码预编译（AOT），开发期将 JS 编译为 Hermes Bytecode 随包分发，运行时直接解释字节码，省去启动阶段的解析与编译；二是无 JIT（或延迟 JIT），避免 JIT 预热期的性能抖动与编译开销，移动端短生命周期页面收益明显；三是内存优化，采用更紧凑的对象表示与并发 GC，降低峰值内存；四是配合 RN 的 snapshot 能力进一步缩短初始化。工程价值：冷启动时间显著下降（可达数十毫秒级收益）、内存峰值更稳，对首屏渲染与低端机体验提升明显。代价：需在构建期接入字节码转换（hermesc），且部分 JS 特性（如 eval 相关能力受限）需兼容验证。

回答抓住"AOT 字节码 + 无 JIT 预热"两个核心机制，再补充内存优化与构建接入代价，形成"机制 → 收益 → 代价"的完整逻辑。

• Impeller 预编译着色器的机制
• 与 Metal 的深度集成
• iOS 上卡顿（jank）消除的效果

Impeller 是 Flutter 的新渲染引擎，核心设计目标是在 iOS（后扩展至 Android 等）上消除 Skia 的"着色器编译卡顿"：Skia 首次遇到新绘制命令时需即时编译 GLSL 着色器，导致掉帧；Impeller 在构建期预编译所有着色器为 Metal 二进制，运行时零编译开销。同时 Impeller 直接基于 Metal 设计渲染管线，利用 Metal 的缓存对象与高效命令编码，减少驱动层开销，并使用更精确的图形原语保证抗锯齿与光栅化质量一致。现代应用上，Flutter 3.10+ 的 iOS 默认启用 Impeller，复杂动画、文本与图片渲染的帧率稳定性与首帧体验明显改善；Android 与桌面端逐步开放，需按版本核查支持状态。

回答聚焦"预编译着色器解决 jank"这一核心，再讲 Metal 集成带来的收益，最后落到版本与平台支持现状，体现时效性。

• Records 匿名聚合与解构
• Patterns 的解构、匹配与 switch 增强
• 在 Flutter 状态与 UI 逻辑中的应用

Dart 3 引入 Records 与 Patterns：Records 是无命名的轻量聚合类型（如 (int, String) 或命名域 (x: 1, y: 2)），可直接返回多值、用作 Map 键，减少定义 DTO 类的样板；Patterns 是广义的"匹配并解构"语法，支持对象解构、List/Map 模式、逻辑或模式与守卫，配合增强的 switch 表达式可写出声明式的分支逻辑。在 Flutter 中价值明显：用 Records 聚合多返回值（如布局计算返回 size 加 offset）；用模式匹配处理异步结果（成功/失败记录解构）、按状态对象（sealed class）分支渲染 UI，替代大量 if/else 与手写类型判断，使 widget 构建逻辑更紧凑、可读且类型安全。

回答先分别定义 Records 与 Patterns，再落到 Flutter 的具体用法（多返回值、sealed class 分支渲染），体现"语言特性 → UI 工程"的连接。

• invoke 命令的定义与注册
• 参数序列化与权限（capabilities）控制
• 异步命令与错误处理

Tauri 中前端通过 invoke('command_name', args) 调用 Rust 后端：Rust 侧用 #[tauri::command] 宏定义函数并注册到 Builder，参数与返回值经序列化协议（JSON 或更高效的消息编码）传递，可返回 Result 表达业务成功/失败。设计要点：命令名与参数结构版本化；通过 capabilities 与权限白名单控制前端可调用哪些命令与作用域（文件、网络等），遵循最小权限；耗时命令用 async 或 spawn 避免阻塞 IPC 线程，同时提供取消机制（EventChannel/取消令牌）处理长任务；错误处理约定统一错误枚举，前端按 code 分支而非解析字符串。调试上可用 devtools 面板查看 IPC 记录，排查序列化失败与权限拒绝。

回答按"定义注册 → 序列化与权限 → 异步与错误 → 调试"组织，突出 capabilities 权限模型与 Result 错误约定两个 Tauri 特有要点。

• 插件结构与注册（registerPlugin）
• iOS（Swift）与 Android（Java/Kotlin）实现
• 权限声明、资源释放与事件回调

Capacitor 插件开发采用"JS 接口 + 双端原生实现"结构：Web 侧用 registerPlugin 声明 TS 接口与默认实现；原生侧 iOS 继承 CAPPlugin（Swift）、Android 继承 com.getcapacitor.Plugin，实现同名方法，通过 CAPPluginCall/PluginCall 返回结果（resolve/reject 带错误码）。工程实践：插件需在原生工程注册并声明所需权限（Info.plist/AndroidManifest 权限与用途说明），满足应用商店合规；长任务在后台线程执行、回调切回主线程；监听原生事件（如系统广播、生命周期）用 notifyListeners 推送给 Web；资源（回调监听、定时器、传感器）在插件销毁时释放，防止泄漏；版本化插件 API，遵循语义化版本并在 README 中明确 iOS/Android 支持矩阵。

回答按"插件结构 → 双端实现 → 权限与线程 → 事件与资源"四个工程维度展开，突出 resolve/reject 错误码统一与资源释放两个易错点。

• 条件编译的语法与平台宏
• 编译期裁剪带来的包体积与隔离收益
• 使用边界与维护纪律

uni-app 条件编译通过注释块（模板中 #ifdef MP-WEIXIN 注释、JS/CSS 中 /* #ifdef MP-WEIXIN */ 注释）标记平台专属代码，编译器按目标平台宏（MP-WEIXIN、MP-ALIPAY、H5、APP-PLUS、APP-PLUS-NVUE 等）在编译期裁剪，未命中平台代码不进入产物。工程价值：平台差异代码物理隔离，避免运行时 if 判断的性能与逻辑噪音；产物按平台瘦身，减少无关代码；多端并行开发时各端可独立验证。注意事项：条件编译是"文本级裁剪"，注释不可省略、宏名必须准确；不能把变量名等逻辑核心放入条件块导致两端行为漂移；平台宏仅控制"代码存在性"，运行时 API 差异仍需能力检测；团队需建立纪律（统一宏规范、评审条件块范围），否则条件块泛滥会降低可读性。

回答先讲机制（编译期按平台宏裁剪），再讲三重价值（隔离、瘦身、并行），最后强调纪律约束（宏规范、能力检测兜底），体现工程管理视角。

• 多端构建链路（Babel 转译 + Webpack 打包）
• 平台编译插件的配置（babel-preset-taro、mini/h5 编译）
• 构建优化与产物治理

Taro 3 构建链路以 Webpack（或 Rspack）为核心：Babel 负责语法转译与编译期转换——babel-preset-taro 按平台预设把 JSX/TSX 转换为对应端的中间代码，注入适配层依赖；Webpack 负责模块打包、资源处理与产物输出，按平台选择编译配置（mini 端输出小程序各文件，h5 端走 web 构建，RN 端走 metro 配置）。工程应用：通过 config/index.js 的 mini/h5 分段配置差异项（chunk 策略、postcss 插件、别名、压缩）；利用 Webpack 的 splitChunks 控制公共代码分包；Babel 插件按需裁剪（如按平台转换 CSS module 行为）。实践中需关注产物一致性验证：同一源码多端构建后跑端到端回归，避免转译差异引发行为不一致。

回答先分角色：Babel 管"语言/平台转换"，Webpack 管"模块与产物"，再讲配置组织与分包优化，最后落到多端产物一致性验证。

• 两引擎的机制差异（运行时 vs 预编译着色器）
• 各平台默认值与支持状态
• 回退机制与性能验证

Skia 是成熟的软件/GPU 渲染库，Flutter 长期默认使用，兼容性与平台覆盖广，但存在首次绘制时的着色器编译卡顿（jank）；Impeller 以预编译着色器与更现代渲染管线消除该问题，且渲染结果更稳定。取舍维度：iOS 从 Flutter 3.10+ 默认 Impeller（早期部分版本可回退 Skia），Android 逐步开放（新版本默认启用，旧版本需 flag 开启），Web/桌面端仍以 Skia（CanvasKit）为主。工程实践：升级后需对目标机型做性能回归（帧率、首帧、内存），对比两引擎表现；关注已知兼容问题（特定 GPU 驱动、复杂 shader 特性）并准备回退开关（--enable-impeller=false 等）；纹理与图片密集型应用需验证 Impeller 的纹理内存策略。

回答按"机制差异 → 平台默认值 → 验证与回退"展开，强调按目标平台与版本核查而非一刀切，体现工程严谨性。