iframe 沙箱管控与 Schema 版本演进

模块一：iframe 跨域预览与微前端管控体系

在低代码或 CMS 系统中，iframe 是实现预览隔离的标准方案。但要做到“生产级”稳定，必须解决生命周期同步与安全隔离问题。

面试避坑：绝不能把 postMessage 比作 TCP。TCP 是底层的持久连接协议，而 postMessage 只是应用层的异步事件订阅/发布模型。

1. 双触发机制（解决生命周期竞态问题）

• 痛点：父页面直接发消息时，iframe 可能尚未挂载或初始化完成，导致消息丢失。
• 机制（状态机握手）：
  • 触发 1（子找父）：iframe 内部组件 onMounted 后，主动发送 。
  • 触发 2（父找子）：父页面监听到 READY 信号后，再将配置数据通过 postMessage 安全下发。

2. 视口模拟（解决响应式失效陷阱）

• 误区：仅在外层 div 使用 transform: scale。这属于“视觉后渲染”，并未改变 iframe 内真实的 window.innerWidth，会导致 CSS 媒体查询（@media）和 vw/vh 单位失效。
• 正解（双层架构）：
  • 内层（定死物理尺寸）：强行修改 iframe 的 width 和 height 为目标机型真实像素（如 375px），以激活移动端响应式代码。
  • 外层（动态缩放）：监听可视区剩余空间，计算比例（如 0.75），用 transform: scale 将外层容器等比缩放。

3. 健壮性与安全防御

• 沙箱隔离（Sandbox）：使用 sandbox="allow-scripts allow-same-origin"。这是浏览器级的硬隔离，防范第三方模板恶意劫持顶层页面（修改 window.parent.location）或弹出干扰 UI。
• 超时保护：父页面加载时开启定时器。若 5 秒内未收到 READY 信号，立刻销毁 iframe 并展示兜底 Error UI，避免用户死等。

4. 父子应用状态哲学

• 单向数据流：父应用（控制台）是“大脑”，掌控 Schema 数据流转；子应用（iframe）是“哑巴组件”，不保存业务状态，只负责接收 JSON 并渲染视图。

---

模块二：Schema 驱动配置与版本演进体系

Schema 驱动的核心思想是“数据即视图”，用 JSON 替代硬编码，实现组件的动态插拔。

1. 配置闭环全链路

1. 定义：用 JSON 描述组件结构（字段、类型、校验规则）。
2. 配置：引擎解析 Schema，自动生成可视化输入面板。
3. 渲染：真实数据存入数据库，预览端（iframe）拿到数据后动态反解并挂载组件。

2. 版本升级难题（面试杀手锏）

• 痛点：当组件库升级（如 V1 只需要 color，V2 改成了 style.color），数据库里存的几千条历史数据会因结构不符导致渲染崩溃。
• 破局解法（版本戳 + 适配器模式）：
  • 打版本戳：所有存入数据库的 Schema 必须带有显式的版本号声明（如 __version: "1.0.0"）。
  • 数据清洗层（Migration Pipeline）：在引擎渲染前加入拦截器。若发现是旧版数据，通过预写的适配函数（Adapter），自动将其 Map（转换）成最新结构。
  • 收益：保证了底层渲染引擎的纯粹性，永远只按最新结构开发。历史包袱全部由清洗层“消化”。