大型后台管理系统如何把业务操作做可靠（16）：多个前端应用如何集成与独立交付
订单、库存和报表由三个团队维护。工作台希望统一登录和导航，同时允许报表独立发布。即使把页面拆成三个部署单元，如果它们共享一个会频繁变化的全局状态，发布仍会互相等待。
先明确业务边界和发布需求
同一技术栈、同一交付节奏时，可以先用单应用加业务模块。每个域维护自己的路由、数据访问与权限契约，跨模块通过公开接口协作。需要历史应用隔离、独立发布或不同运行时共存时，再比较按路由跳转、iframe 和运行时加载。
| 方式 | 适用情况 | 需要承担的成本 |
|---|---|---|
| 同应用模块 | 发布节奏一致，交互紧密 | 单一产物，靠模块边界治理 |
| 按路由独立应用 | 可以按页面划分责任 | 统一身份、深链接、返回与导航 |
| iframe 集成 | 旧应用需要独立文档和样式环境 | 布局、键盘、会话及跨窗口消息 |
| 运行时加载 | 需要在主应用中无缝组合 | 依赖、版本协商、隔离和卸载 |
独立发布与依赖共享之间存在取舍。共享同一个运行时可能降低下载量，也会要求各应用接受兼容版本。Cam Jackson 的微前端文章讨论了这些成本，Shopify 的模块化单体案例也说明了在单一部署内建立维护边界的方法。Micro Frontends · Shopify 的模块化单体复盘
给主应用和子应用一份协议
主应用维护导航、租户上下文和错误边界。子应用取得经过定义的上下文，在自己的容器内渲染，并负责清理监听、订阅与正在执行的查询。不要把不同应用之间的业务模型全部塞进一个共享对象。
mount(container, hostContext):
requireSupportedProtocol(hostContext.protocolVersion)
subscribeToTenantChanges()
renderInto(container)
return disposeSubscriptionsRequestsAndView跨应用传递订单 ID 和业务事件语义，接收方按自己的接口读取并鉴权。iframe 通过消息交换时验证来源、目标窗口与消息结构。主应用动态加载清单时应限定可信来源和兼容版本。加载失败可显示具体子应用的故障与重试入口，工作台导航和其他模块仍可使用。
用一次报表迁移验证拆分依据
假设报表代码原本在工作台里，后来希望由独立团队交付。先把报表对主应用的依赖列出来。导航、当前租户和登录恢复可以成为主应用契约。报表筛选、计算口径和下载由报表域维护。若两个应用仍直接修改同一份全局订单状态，先处理这个共享约束，部署方式变化本身无法解除耦合。
可以先切出独立路由，在真实环境验证深链接、返回和租户切换。如果工作台仍需要在同一个页面内嵌入报表摘要，再比较共享组件、独立请求和运行时集成。采用运行时加载时要有版本清单，包含入口资源、宿主协议范围和应用版本。加载前检查版本，失败时在模块区域展示恢复入口。避免回退时动态清单引用已清理的分包。
将加载和卸载写成对称的责任
挂载前建立应用实例，实例拥有自己的容器、事件监听、定时器与请求生命周期。切换到其他模块时销毁这些资源，并使旧请求结果失效。如果挂载中途失败，已经创建的监听和订阅仍需清理。主应用切换租户时先改变可信上下文，再通知各子应用重读数据。子应用显示上一租户的数据前应检查其是否仍属于当前实例。
| 破坏性变化 | 需要验证的组合 |
|---|---|
| 主应用升级上下文协议 | 旧报表能挂载或得到明确的兼容提示 |
| 报表切换运行时 | 主应用导航、登录和其他子应用仍可工作 |
| 报表资源不可访问 | 报表显示错误与重试，订单页可继续操作 |
| 子应用多次进出 | 监听与订阅数量不持续增长 |
若 iframe 里需要通知父窗口打开订单，消息只传经过校验的动作与资源 ID，父窗口自行完成导航和授权。明确双方可接收的来源、窗口和结构。读写会话或敏感数据应通过受控契约，避免借跨窗口消息传完整令牌。
验收各团队能否真的独立发布
保留旧主应用，部署新报表，直接打开报表深链接并切换租户。让报表资源加载失败，确认订单模块仍可用。反复挂载和卸载子应用，检查全局样式、事件、订阅与内存。发布记录应能还原当时主应用和每个子应用的版本，便于单独回退和复盘。
处理一次独立回退
假设工作台宿主支持协议第 2 版，报表构建 B 使用该协议。故障后希望把报表切回 A。发布前要知道 A 支持哪些宿主版本、它的入口和分包是否还在、当前 API 是否仍接受 A 的请求。如果宿主升级已删除 A 依赖的能力，就不能只修改报表清单完成回退。
更稳妥的交付记录会写出实际验证过的组合，包括宿主版本、报表构建、协议版本和接口兼容范围。每个子应用发布后，把它和仍在线的宿主版本组装验证。若加载失败，只在子应用区域显示当前版本和可恢复入口，公共导航仍可工作。关键的订单处理和退款入口可以有独立的故障处理策略。
跨应用导航也要验收旧链接。报表点击一笔订单时只带租户上下文允许传递的资源标识，订单应用按当前会话读取。若租户刚切换，旧链接不应展示另一租户的结果。自动测试可以先打开报表，再让订单应用加载失败并恢复，最后在两个应用之间往返，检查 URL、标题、焦点和订阅清理。
总结
前端集成先解决责任与通信，再决定部署结构。能独立发布的模块，要有清楚的版本协议、卸载边界和故障隔离方式。