跨端框架的「编译时」与「运行时」方案有何本质差异？

以 Taro 为例：Taro 1/2 是编译时方案——把 JSX 在构建期编译成各小程序的 WXML 模板，运行时代码薄、性能好，但 JSX 表达能力受模板语法限制（动态结构、高阶组件难完整支持）；Taro 3 转向运行时方案——在小程序逻辑层模拟 DOM/BOM，跑完整的 React/Vue 协调过程，把虚拟 DOM diff 结果映射为 setData 更新，表达能力接近完整 Web 生态，代价是运行时开销与包体增大。

本质矛盾：小程序没有 DOM，框架要么在编译期把声明式 UI 静态映射到模板（牺牲动态性），要么在运行时维护虚拟树再同步（牺牲性能）。优化方向是混合路线：预编译静态部分、按需与局部 setData、虚拟列表减少通信量。易错点：运行时方案下操作真实 DOM 的库（部分图表库）需适配；setData 数据量过大是小程序性能头号杀手。追问：小程序双线程模型（逻辑层与渲染层分离）对框架设计的约束。