微前端架构

• qiankun 基于 single-spa 的架构：生命周期 + 路由驱动 + 应用注册
• qiankun 相对 single-spa 的增强：HTML Entry、沙箱、样式隔离、预加载
• 工程边界：兼容策略、性能成本与现代架构的适用性

qiankun 建立在 single-spa 的「路由驱动 + 应用注册 + 生命周期」模型上：single-spa 提供应用注册表与激活判定（activeWhen）、生命周期协议（bootstrap/mount/unmount）与路由接管，qiankun 在其上补齐微前端落地能力——HTML Entry（import-html-entry 解析远程 HTML 的 script/style 并按序执行）、JS 沙箱（Snapshot/Proxy 系列）、样式隔离（scoped css）、应用通信（globalState）、预加载（prefetch）与错误处理。工程边界：兼容优先——qiankun 主打「存量系统快速接入」，任何技术栈的存量应用只要补生命周期导出即可接入（低改造成本），这是其相对现代方案的差异化优势；性能成本——Proxy 沙箱的 trap 开销、HTML Entry 的运行时解析（相对构建期联邦）在极端性能场景有成本；隔离强度——应用层沙箱存在逃逸面，高安全场景需 iframe 兜底。现代应用：作为「存量改造 + 渐进迁移」的首选（路由级绞杀、多技术栈共存）；与 Module Federation 的关系——qiankun 解决「应用编排与运行时隔离」，MF 解决「模块共享」，现代工程常「qiankun 管应用、MF 管依赖共享」组合使用；团队独立发布、基座统一治理的架构下，qiankun 的注册模型（registerMicroApps / loadMicroApp）支撑按需加载与动态注册。

回答按「single-spa 基座能力 → qiankun 的增强（entry/沙箱/隔离）→ 工程边界（兼容、性能、隔离）→ 现代定位（存量改造 + 与 MF 组合）」组织，核心是「qiankun 的价值在兼容接入与运行时治理，边界在性能与隔离强度」。

• micro-app 的自定义元素容器模型与注入机制
• 样式隔离双模式（元素 scoped / shadow）与 JS 沙箱
• 工程实践要点：兼容、通信与多实例

micro-app 的核心是「自定义元素即应用容器」： 在页面中声明子应用，框架在 customElement 内注入子应用的 HTML/JS/CSS——容器语义天然「自包含」（样式与 DOM 边界由元素封装提供一部分），配置即接入（无需改写代码为生命周期函数，比 qiankun 的导出契约接入成本更低）。工程实践：样式隔离双模式——默认「元素级 scoped」（给子应用根元素加标识属性并改写选择器，成本低兼容好），可选 shadow 模式（更强封装，需适配全局样式依赖）；JS 隔离——复用 Proxy 沙箱思路 + 元素作用域绑定，支持多实例（同一子应用挂多个容器）；通信——基于 CustomEvent 的组件化通信（micro-app 元素派发事件，基座监听），贴合 Web 组件语义；加载——按元素加载远程资源（HTML/JS/CSS 注入容器），支持预加载与缓存。取舍：优势是接入体验（声明式、零生命周期改造）、与 Web 平台模型一致（元素化）；边界是「运行时注入解析」的性能成本（相对构建期联邦）、HTML 解析与执行的安全面（需 CSP 与资源校验配合）、shadow 模式的生态适配。工程定位：适合「希望低门槛接入 + 元素化语义」的场景，与 qiankun 相比更「Web Components 原生」。

回答按「自定义元素容器模型 → 双模式样式隔离与沙箱 → 通信与加载实践 → 取舍定位」，核心是「micro-app 用元素模型换接入体验，隔离能力仍靠运行时沙箱」。

• 无界的 iframe JS 沙箱 + WebComponent DOM 容器模型
• 渲染与通信的桥接机制
• 工程应用场景与取舍

无界的模型是「iframe 执行 JS + WebComponent 承载 DOM」：子应用 JS 在隐藏 iframe 的独立全局执行（JS 隔离最强、无代理逃逸面），渲染的 DOM 被「搬移」到主文档的 shadowRoot（或元素容器）中呈现——JS 运行环境与 UI 呈现分离，兼具 iframe 的强隔离与 Web Component 的组合体验。工程应用：强隔离场景（多技术栈共存、不可信第三方应用、对隔离强度要求高的业务）；渲染桥接——无界把 iframe 内 DOM 同步到主文档容器，配套处理样式（容器内 scoped/样式穿透）、事件（事件委托到容器）、弹窗与浮层（脱离 iframe 边界显示，解决传统 iframe 的弹窗裁剪问题）；通信——框架内建桥接通道（非纯 postMessage 的定制通道），支持 props/事件/方法调用跨边界。工程价值与取舍：价值是「隔离强度与呈现质量兼得」——相比纯 iframe 规避了弹窗与焦点问题，相比 Proxy 沙箱消除了逃逸面；代价是「双份 DOM 与桥接成本」——iframe 内 DOM 与主文档 DOM 的同步有性能开销、可观测性有盲点（iframe 内错误与性能需桥接上报）、对「重 DOM 应用」（大表格、高频更新）需评估桥接成本。应用场景：对隔离与体验要求双高的生产环境；配合「保活」缓解初始化成本。

回答按「双沙箱模型（iframe 执行 + WebComponent 呈现）→ 桥接机制（DOM 同步、事件、弹窗）→ 价值与代价（隔离/呈现 vs 桥接开销）→ 应用场景」组织，核心是「无界用分层换兼得：JS 隔离交给 iframe、呈现质量交给 DOM 桥接」。

• garfish 的架构：路由驱动、模块加载与沙箱
• 设计特点：插件化、性能导向与框架无关
• 工程边界：生态成熟度、兼容性与现代演进

garfish 的架构围绕「应用治理」设计：路由模块（basename 前缀匹配驱动激活）、模块加载（按需加载子应用资源）、沙箱（window 代理隔离 + 副作用清理）、生命周期与钩子体系（app 级钩子 + 插件化扩展）。设计特点：性能导向——沙箱侧重「记录-恢复」的成本控制、资源加载按需与预取编排，官方宣传侧重首屏与切换性能；框架无关——生命周期协议不绑定具体框架（任何框架补契约即可接入），与 qiankun 定位相近但实现差异在「沙箱记录模型（LegacySandbox 类似机制演进）」与「router-based 激活」；插件化——加载、解析、渲染等环节可扩展，便于企业按需定制。工程边界：生态与文档成熟度相对 qiankun/micro-app 较新（社区规模、问题沉淀有限）；接入成本——同样需要子应用改造（生命周期导出）与基座配置；与现代构建（Vite/联邦）的协同处于演进中（原生模块加载与联邦共享的取舍）。定位：国产化生态中的「字节系方案」，适合「需要插件化定制 + 性能敏感」的团队评估，与 qiankun 的选择本质是「同一模型下的工程取向差异」。

回答按「架构能力（路由/加载/沙箱/钩子）→ 设计特点（性能导向、插件化、框架无关）→ 工程边界（生态、接入、现代协同）」，核心是「框架选型看工程取向：兼容生态 vs 插件定制 vs 性能导向」。

• import-html-entry 的解析：HTML → 模板、scripts、styles 提取
• 加载流水线：fetch → 解析 → 执行（样式/脚本注入）→ 沙箱执行
• 流水线要点：资源地址改写、执行顺序、缓存与错误处理

import-html-entry 是 qiankun 的远程 HTML 加载器：fetch 子应用入口 HTML → 解析出模板（body 内容）、样式列表（link/style）、脚本列表（inline 与 src）→ 把相对路径改写为子应用基址（对齐 publicPath）→ 返回「模板 + 样式 + 脚本」的结构供框架注入执行。应用加载流水线：fetch entry（带超时与重试）→ 模板解析与资源提取 → 样式注入（link 转 style 或保持 link，动态插入容器）→ 脚本执行（inline 脚本用 with + Proxy 包装在沙箱上下文执行、src 脚本动态创建 script 标签加载后执行，按 HTML 中的顺序）→ 生命周期触发（子应用脚本执行后暴露生命周期，框架调用 bootstrap/mount）→ 挂载渲染。流水线要点：执行顺序——HTML 中脚本的依赖顺序必须保持（同步执行语义），异步改造需谨慎；资源地址——所有相对路径（脚本、样式、图片）统一改写，否则子应用在非入口路径部署时 404；缓存——fetch 结果与解析结果可缓存（同一版本 entry 不重复拉取解析），注意与发布版本联动；错误处理——entry 加载失败、脚本执行失败（沙箱外抛错）进入降级路径；CSP 冲突——严格 CSP 下「运行时注入并执行内联脚本」受限，需 nonce 或改模块通道。现代对比：import-html-entry 是「运行时解析 + 执行」模型（灵活但每次解析有成本），webpack/vite 联邦是「构建期产物 + 运行时协商」模型（性能与类型更优，但要求构建体系配合）——现代工程倾向「HTML entry 兼容存量 + 联邦优化增量」。

回答按「entry 解析机制 → 加载流水线（fetch/解析/注入/执行/挂载）→ 要点（顺序、路径、缓存、CSP）→ 与联邦模型的对比」组织，核心是「HTML Entry 的灵活来自运行时解析，成本与限制也随之而来」。

• 运行时共享的模型：share scope 注册与消费
• 版本协商流程：requiredVersion、singleton、版本比对
• 协商结果的运行时语义：复用 vs 自载、单例与告警

运行时共享模型：依赖被声明为 shared 后，各应用运行时向「共享作用域（share scope）」注册自己加载的依赖（模块 + 版本），消费方加载共享依赖时不是「自己再加载」，而是「向共享作用域请求」——作用域按版本协商决定「返回已有实例」还是「加载新版本」。版本协商流程：消费方声明 requiredVersion（semver 范围）与策略（singleton 是否强制单例、strictVersion 是否严格校验），运行时把「已注册的版本」与「requiredVersion」比对——范围内直接复用；范围外且非单例，加载自己的副本（共存）；单例且范围外，默认降级复用并告警（strictVersion 时升级为报错）。协商结果的运行时语义：复用——同一实例（框架单例、共享 store 状态一致）；自载——多副本并存（隔离但体积与状态分裂）；版本协商失败的模式：invalid hook call（React 双实例）、上下文断裂（Provider 双实例）、单例状态分叉。工程治理：requiredVersion 用「合理宽范围」（兼容升级）+ singleton 只给框架类；契约测试覆盖「版本组合 × 加载顺序」；snapshot 锁定发布时状态。核心认知：联邦共享是「运行时协商」而非「构建期约定」，协商质量决定共享收益与故障风险。

回答按「共享模型（作用域注册与消费）→ 协商流程（版本比对 + 策略）→ 运行时语义（复用/自载/故障）→ 治理」组织，核心是「版本协商把『能不能共享』变成运行时决策，决策质量靠策略与测试保障」。

• 三种拆分维度的粒度与归属：域/页/功能
• 各维度的团队边界、独立性与耦合度
• 拆分策略的决策框架

三种拆分维度：按业务域——以「完整业务闭环」为单位（订单域、用户域），一个域含多页面与完整逻辑，团队独立负责域内全部能力；收益是团队边界最清晰（康威定律对齐）、独立发布与演进能力最强；代价是域间共享逻辑（公共组件、跨域流程）需治理、粒度较大（单域可能较大）。按页面——以「页面」为单位拆分（每个页面一个应用）；粒度细、切换直观（路由级激活），适合「页面间关联弱、共享少」的场景；代价是页面级团队协作（同一业务域多页面被多个团队拥有时跨团队协调多）、页面间状态共享困难。按功能——以「功能模块」为单位（搜索、推荐、购物车），粒度最细、复用与独立部署最灵活，适合「平台型页面」（多团队各自提供功能块拼装 dashboard）；代价是「页面被多个应用拼装」的编排复杂度（布局、通信、加载编排）高、功能间耦合控制难。决策框架：先按「团队边界（谁能独立交付）」定域，再按「页面关联度」决定域内是否再拆，功能级拆分的先决条件是「拼装编排能力成熟」；核心权衡永远是「独立性收益 vs 集成复杂度」，拆分粒度服从「团队能最小协调地交付完整用户价值」。

回答按「三维度机制与收益代价 → 决策框架（域为纲、页与功能为目）→ 核心权衡」组织，核心是「拆分粒度先匹配组织（域），再匹配编排能力（页/功能）」。

• EMP 的定位：MF 之上的工程化平台（共享、治理、可视化）
• 扩展能力：远程共享、版本管理、依赖治理、devtools
• 价值与边界：共享收益 vs 平台依赖

EMP 是「MF 的工程化增强层」：MF 提供联邦原语（exposes/remotes/shared），EMP 在其上补「平台级治理」——远程共享的目录化（共享模块的注册、检索与文档化）、版本管理与冲突治理（共享依赖的版本策略、升级通知与兼容校验）、依赖分析（哪些应用共享了什么、版本是否漂移）、开发工具链（devtools 面板：查看联邦拓扑、共享依赖协商结果、加载状态）、发布协同（产物与 remoteEntry 的 CI/CD 集成）。工程价值：把 MF 的「机制」变成「平台能力」——团队接入共享时不必各自摸索协商细节，平台统一策略（如共享依赖清单、singleton 策略模板）；可观测性（联邦状态可视化：谁加载了谁、共享命中与失败）；治理闭环（版本漂移检测、契约校验门禁）。边界：EMP 引入「平台依赖」——团队按平台约定接入（共享登记、配置规范），平台本身的演进（升级、故障）影响全局；更适用于「统一技术治理的中大型组织」（多团队、多应用的联邦生态），小团队单应用场景平台收益不明显；与 MF 原生能力的关系——EMP 不替代 MF 机制，而是「策略与工具的收口」，选择时评估「团队协作复杂度是否值得平台化」。

回答按「定位（MF 之上的治理层）→ 扩展能力（目录、版本、分析、工具）→ 价值（统一策略与可观测）→ 边界（平台依赖与适用规模）」组织，核心是「EMP 解决的不是联邦怎么跑，而是联邦怎么管」。

• icestark 的定位：阿里 ice 体系的微前端框架（框架无关、轻量）
• Garfish 的字节系定位与其能力
• 两者的工程取向：生态绑定、接入模型与治理

icestark 是阿里 ice 体系的微前端方案：设计取向「框架无关 + 轻量」——核心只做「应用管理与路由分发」（微应用注册、URL 匹配、加载与卸载），JS 隔离默认不强（依赖应用自觉或配合沙箱方案），文档与工程化沉淀在 ice 生态（脚手架、路由约定、构建集成）；价值在于「阿里生态内快速起步」（与 ice 组件、构建、发布链路整合），适合「阿里技术栈 + 低侵入」团队。Garfish（字节跳动）侧重「治理完整」：路由、加载、沙箱（window 代理 + 副作用清理）、插件化、生命周期钩子齐备，性能导向（沙箱与加载优化）；价值在于「复杂多团队场景的完整治理能力」与「插件化定制」。两者对比的工程判断：icestark「少而稳」（核心职责单一，隔离等能力由使用者按需组合）、Garfish「全而活」（开箱全量能力，插件可定制）；选择取决于「技术生态契合（ice 系 vs 中立）」与「治理需求深度（轻量接入 vs 完整治理）」。共同点：都走「运行时加载 + 生命周期协议」的经典模型，与现代构建联邦协同都需要额外设计。

回答按「各自定位与设计取向（轻量路由型 vs 完整治理型）→ 生态价值（ice 契合 vs 中立插件化）→ 选型判断」组织，核心是「框架选型匹配技术生态与治理深度，而非功能清单」。

• requiredVersion：semver 范围的声明与协商匹配
• singleton：强制单例与版本校验的语义
• strictVersion：把告警升级为报错的行为

三个配置协同决定共享协商：requiredVersion——声明「本应用要求该依赖的版本范围」（semver），协商时把共享作用域已注册版本与该范围比对：范围内复用、范围外自载（非单例）；它是「版本匹配」的基准。singleton——声明「该依赖必须全局单例」（框架类依赖必须开）：singleton: true 时即使版本不匹配也不自载（避免双实例），而是「降级复用 + 告警」——降级复用（用已注册版本）保证运行时一致，告警提示版本不满足（用户可见 console 警告）。strictVersion——与 singleton 配合：「strictVersion: true 时，singleton 的版本不满足 requiredVersion 从『告警降级』升级为『报错』」——联邦运行时直接抛出错误（拒绝加载），强制团队解决版本问题而非带病运行。典型场景（以 React 为例）：宿主 React 18、远程 requiredVersion ^18，协商命中复用；远程升到 React 19 且 requiredVersion ^19，宿主仍是 18——非单例则远程自载 19（双 React 共存，invalid hook call 风险）、singleton 则降级复用 18 并告警、singleton + strictVersion 则直接报错阻止加载。工程要点：框架依赖必须 singleton（双实例必炸）、requiredVersion 用「合理宽范围」（太窄造成不必要自载、太宽掩盖不兼容）、strictVersion 用于「版本不一致 = 运行时风险」的场景（让问题在加载期暴露而非运行期崩）、契约测试验证「版本组合 × 策略组合」的实际行为。

回答按「三配置各自的协商语义 → 组合行为矩阵（以 React 为例）→ 工程配置要点」组织，核心是「requiredVersion 定匹配、singleton 定共存与否、strictVersion 定失败模式」。

• 各框架的路由接管与激活模型
• 主子应用路由协同的实现（hash/history、前缀约定）
• 三者的路由行为差异与选型

三者的共同模型是「基座路由接管 + 子应用按前缀激活」：single-spa——最底层：基座用自己的路由库（或裸监听）驱动，activeWhen 判定激活，子应用内部路由自主管理（single-spa 不强制路由协议，导航由应用自己处理，基座通过 urlReroute 感知变化）；qiankun——基于 single-spa 的注册模型（registerMicroApps + activeRule 路径前缀），子应用内部路由与基座路由「同步」（history 模式子应用路由挂在基座路径下，通过「主子路由同步」机制保证子应用内导航不逃出基座管控）；wujie——iframe 内子应用有「自己的完整路由」（独立 window.history），与基座路由通过「路由同步」桥接（基座路径变化反映到 iframe 内、子应用内导航同步回基座 URL），导航与「应用切换」的语义由桥接层协调。实现要点：前缀规划——子应用路由统一挂独立前缀（/app1/*）避免与基座路由冲突；hash vs history——hash 模式天然挂在基座 hash 下（子应用冲突少）、history 模式需前缀约定与「找不到路由回退」处理（子应用内刷新与直接访问 URL 的兜底）；激活时序——路由命中 → 加载 → 挂载 → 路由切换的卸载编排（含竞态）。差异选型：single-spa 最灵活（自己组装一切）、qiankun 托管式（注册即用、路由同步内置）、wujie 隔离式（iframe 内独立路由 + 桥接同步）——按「对子应用路由自主性的要求」选择。

回答按「共同模型（基座接管 + 前缀激活）→ 三者的路由实现差异（自管/同步/桥接）→ 实现要点（前缀、模式、时序）→ 选型」组织，核心是「路由协同的本质是『基座拥有 URL、子应用拥有片段』的边界划分」。

• 2.5+ 的版本演进背景与能力升级
• 新增特性的机制与价值：运行时增强、类型、调试
• 与 2.0 的能力衔接与工程影响

MF 2.x 系列在 2.0（独立 runtime + runtimePlugins + snapshot）基础上持续增强：2.5+ 的重点方向是「类型安全、调试体验与生态衔接」——类型系统完善（远程模块的完整类型生成与校验，缓解「远程无类型」的工程痛点）、调试工具增强（联邦运行时面板：查看共享作用域、远程加载状态、插件执行链路）、与构建生态的适配（Vite/Rspack 接入稳定化）、以及运行时 API 的完备（远程模块的同步/异步加载编排、错误语义统一）。特性价值：类型——把「契约靠文档」变成「契约靠类型」（跨团队共享模块的类型同步，编译期发现接口断裂）；调试——联邦黑盒变可观测（协商失败、加载失败的原因可查，问题定位从「猜」到「看」）；生态——现代构建器（Vite/Rspack）的联邦体验对齐 webpack，降低「构建器迁移 vs 联邦使用」的两难。工程影响：升级路径——从 1.x/2.0 迁移的兼容（runtime 版本协商与插件 API 演进）、共享依赖策略在新版本下的行为一致；2.5+ 更适合「多团队、远程模块多、需要契约与可观测」的大型工程，小型工程升级收益有限。核心认知：2.5+ 是「机制成熟后的工程化补完」——联邦的「能跑」问题已解决，新版本解决「跑得好、可维护」问题。

回答按「演进背景 → 特性能力（类型、调试、生态）→ 价值（契约化、可观测、构建中立）→ 迁移与适用性」组织，核心是「2.5+ 解决联邦的工程化短板：类型与可观测性」。

• 路由分发的数据结构：应用注册表、路由表与匹配算法
• 模块加载：依赖图、缓存与加载编排（队列、竞态）
• 状态同步：状态树、版本号与订阅分发

路由分发：核心数据结构是「应用注册表（App Registry）」——每个条目含 name、activeRule、entry、生命周期引用；匹配算法——按注册顺序对当前 URL 逐条执行 activeRule（前缀匹配/正则/函数），命中集合决定「激活哪些应用」；分发正确性依赖「规则互斥 + 顺序稳定」（重叠规则的优先级要显式）。模块加载：数据结构是「模块图 + 加载缓存表」——依赖关系图（子应用 → 入口 → 资源）、已加载缓存（URL → 模块实例）；算法要点——加载队列（同一应用并发触发只加载一次，其他等待）、竞态控制（快速切换时「代际/序列号」判定响应有效性，只接受最新代）、预加载调度（空闲时按优先级队列加载下一候选）。状态同步：数据结构是「共享状态树 + 订阅表」——globalState/store 的状态树（按域分片）、订阅者表（状态路径 → 监听器集合）；算法要点——变更广播（按「变更路径」分发而非全量，配版本号让订阅方做「去重与拉取决策」）、剪裁（订阅方选择器比较，避免过度渲染）。工程意义：这三个子系统是微前端的「运行时内核」，其数据结构与算法的正确性（互斥匹配、幂等加载、收敛同步）直接决定架构的稳定性——面试与设计时按「注册表/缓存表/状态树 + 匹配/编排/分发算法」建模，可系统性覆盖微前端运行时设计题。

回答按「三子系统的数据结构（注册表、模块图/缓存、状态树/订阅表）与算法（匹配、加载编排、版本分发）」组织，核心是「微前端运行时 = 三类表 + 三类算法」，用统一建模理解运行时设计。

• Bit 的模型：组件作为独立可发布单元（component-driven）
• 组件级微前端：跨项目共享与独立版本演进的机制
• 与应用级微前端的对比与互补

Bit 的核心理念是「组件即构建单元」：每个组件独立开发、版本化、构建与发布（组件仓库），任何项目通过安装（npm 或 Bit 运行时）消费组件——实现「跨项目/跨团队的组件级共享与演进」，是「组件级微前端」的代表：共享粒度不是「应用」而是「组件」，组件有独立版本与依赖图，升级按组件各自节奏。工程价值：渐进共享——不需要整应用接入微前端，先共享高频复用的组件（UI 库、业务组件）即获收益；版本演进自治——组件独立版本、独立发布，消费方按版本升级（与应用级微前端的「应用版本矩阵」比，粒度更细）；依赖治理——组件级依赖图清晰（谁依赖谁、版本兼容），避免应用级「巨石共享包」的耦合；协作模型——组件 owner 制（跨团队共享时职责明确）。与应用级对比：应用级微前端解决「独立部署与运行时组合」（团队独立交付完整功能），组件级解决「跨项目复用与演进」（团队共享组件资产）——两者不是替代：应用级微前端内部依然需要组件复用策略，组件级共享做得好的组织，应用级微前端可专注「编排与隔离」。边界：组件级共享对「组织协作文化」要求高（共享组件需要治理：契约、文档、变更通知），纯组件共享解决不了「运行时隔离、独立部署、团队自治」等应用级问题。

回答按「Bit 模型（组件即单元）→ 工程价值（渐进共享、版本自治、依赖清晰）→ 与应用级对比与互补 → 边界」组织，核心是「组件级解决复用演进、应用级解决部署编排，粒度不同、互补不替代」。

• 主应用路由的职责：全局导航、应用激活与归属判定
• 子应用路由的职责：应用内导航、视图状态
• 分发实践：前缀、同步、回退与跨应用跳转

分工原则：「主应用拥有 URL 的全局结构，子应用拥有前缀下的局部结构」——主应用路由负责全局导航（顶部导航、Tab、应用入口）与激活判定（当前 URL 归属哪个应用、加载与卸载编排）；子应用路由负责其管辖路径内的页面与视图状态（应用内二级导航、详情页、参数）。工程实践：前缀规划——子应用独占路径前缀（/app1/*），主应用路由表与子应用前缀互斥；同步机制——history 模式下子应用内部导航更新 URL（落在自己前缀内），主应用「不拦截、不接管」该前缀内的导航（子应用自管），跨出前缀的导航（跳转其他应用/全局页）必须经主应用路由（子应用调用注入的跳转能力）；回退处理——子应用前缀下的未知路径（直接访问 URL、刷新）由子应用自己的「404/兜底路由」处理（或主应用回退到全局 404），不能让主应用吞掉子应用域的路径；状态与守卫——子应用路由守卫（登录态、权限）由子应用自行处理，全局守卫（全局登录、全局布局）在主应用层；hash 模式——子应用路由天然挂在主应用 hash 之后（URL 的一部分），同步成本低但 URL 语义弱；「路由状态外置」——需要跨应用恢复视图时（刷新后回到子应用具体页），把子应用路由状态写进 URL（search/hash），主应用不做二次记忆。工程要点：激活规则用「精确前缀 + 白名单」避免误激活；路由变化的事件化（主应用监听 URL 变化驱动生命周期）；「同 URL 不同权限」由守卫层处理。

回答按「职责分工（全局 vs 局部）→ 分发实践（前缀、同步、回退、跳转）→ 状态外置与守卫」组织，核心是「路由分发 = 边界划分 + 同步约定 + 兜底处理」。

• 两种共享机制的时机：构建期打包 vs 运行时共享
• 版本治理与体积的权衡
• 选型框架：框架类、工具类与业务共享

共享 npm 包：各子应用构建期把公共依赖打进自己的产物——机制简单（构建器原生）、类型与调试完整、无运行时依赖（离线可用、部署独立），代价是「版本漂移」（各应用依赖版本可能不一致，行为差异与升级协同成本）与「重复体积」（每个应用打包一份，页面加载总量大）。MF shared：运行时共享——一个实例、协商版本（requiredVersion/singleton），代价是「运行时依赖」（共享实例加载失败影响所有消费方）、协商复杂度（版本组合需要测试）、调试与类型要额外治理。适用场景：框架类依赖（React/Vue 等「双实例必炸」的）——必须 MF shared + singleton（或 CDN external），因为 npm 共享无法保证运行时单例（版本漂移直接导致 invalid hook call）；工具类（lodash、axios 等无状态纯函数/实例无关的）——MF shared 收益主要在体积（避免重复打包），版本漂移风险低，可按「体积收益 vs 协商复杂度」权衡；业务共享（业务组件、状态库）——版本语义强（业务逻辑演进而非纯兼容），建议 npm 版本化管理（契约测试 + 兼容矩阵）而非运行时共享（运行时共享业务模块的升级是「隐式全量变更」，风险大）。工程组合：框架层 MF shared + singleton（运行正确性）、工具层视体积共享（性价比）、业务层 npm + 契约治理（演进可控）——「共享机制按依赖的『运行语义』选型」。

回答按「两机制对比（时机、版本、体积）→ 按依赖类别选型（框架/工具/业务）→ 组合实践」组织，核心是「共享方式由依赖的运行语义决定：要单例的运行时共享、要演进的版本化共享」。

• 三阶段的职责划分与调用时机
• mount/unmount 的幂等与异步语义
• 生命周期与框架（React/Vue）的映射实现

三阶段协议（single-spa 系）：bootstrap——「初始化一次」：应用第一次加载时执行（设置全局环境、初始化配置、创建全局实例），多次激活不重复执行（框架缓存）；mount——「每次挂载」：创建/恢复应用实例并渲染到容器，接收参数（容器、props、路由），可多次调用；unmount——「每次卸载」：销毁应用实例、清理副作用（DOM、监听、定时器、状态），返回 Promise 表示清理完成。实现要点：幂等——mount 重复调用不叠加（渲染前检查是否已挂载）、unmount 重复调用不报错（清理幂等）；异步——mount/unmount 返回 Promise，基座串行编排（等待旧卸载完成再挂载新的，防竞态）；超时与错误——生命周期执行超时/抛错进入降级路径（告警、强制清理容器）；框架映射——React：bootstrap 通常空实现、mount 用 createRoot().render（或 hydrate）、unmount 用 root.unmount()；Vue：mount 用 createApp().mount、unmount 用 app.unmount()——关键是「框架实例的生命周期与协议对齐」（挂载/卸载都要通过框架 API 而非裸 DOM 操作，保证框架的清理钩子触发）。工程要点：生命周期导出为「独立模块」（不被构建摇掉——entry 打包配置）；生命周期内不要做重活（长初始化放异步加载阶段）；「保活」语义——keep-alive 时 mount/unmount 退化为「显隐 + 暂停/恢复」（不真实销毁），协议层用「激活/失活」事件补充。

回答按「三阶段职责与时机 → 幂等/异步/错误契约 → 框架映射与保活」组织，核心是「生命周期是基座编排子应用的契约，正确性靠幂等与异步语义」。

• 三类通道的语义与适用场景
• 通信的耦合度模型：显式、广播、共享
• 通信治理：契约、命名空间与生命周期

三类通道按「耦合度」分层：props——显式定向（基座向子应用传参、回调，子应用向基座汇报事件）：强语义、类型化、依赖显式，适合「父子关系的受控交互」（初始化数据、跳转回调、请求实例注入）；CustomEvent——广播松耦合（页面级事件：登出、语言切换、数据刷新通知）：一对多、无方向性、事件即协议，适合「不关心谁处理」的全局通知；状态管理（globalState/共享 store/URL/Storage）——共享数据层（跨应用读取同一状态：用户会话、主题、筛选条件）：有状态、可订阅、适合「多应用共同读写的数据」。分工原则：能 props 就不用事件（定向 > 广播）、能事件就不用共享状态（消息 > 数据）、共享状态只放「真正共享的」；通信的耦合控制：契约化——消息/事件/状态字段定义成版本化契约（类型 + 文档），变更走兼容流程；命名空间——事件与状态键按「应用域」隔离，避免冲突；生命周期——事件监听与状态订阅随应用卸载清理，防止「幽灵订阅」与泄漏；可观测——通信日志（谁发了什么、谁在处理）支持问题定位。工程实践：基座提供「通信 SDK」（封装三通道 + 类型 + 日志），子应用不直接操作裸通道；「通信矩阵」文档化（哪个应用与谁通信、用什么通道、契约版本）。

回答按「三类通道的语义分层（定向/广播/共享）→ 分工原则 → 治理（契约、命名空间、生命周期、观测）」组织，核心是「通道选择 = 通信关系的耦合意图，治理让通道可控」。

• preload/prefetch 的语义差异（当前需要 vs 未来可能）
• 子应用级预加载（框架 prefetch）与资源级预加载
• 编排策略：时机、优先级、成本控制

语义差异：preload——「当前页面即将使用」的资源，高优先级立即加载（适合当前路由子应用的首屏关键资源：入口、核心 chunk）；prefetch——「未来可能使用」的资源，空闲时低优先级预取（适合下一级路由的子应用入口与高频 chunk）。微前端中的两层预加载：框架级——qiankun 的 prefetch 子应用（激活前预取 entry 资源）、MF 的 prefetch remote（提前拉取远程模块元数据与核心模块）——解决「切换时的加载等待」；浏览器级——preload/prefetch link 标签、Speculation Rules（导航级预取/预渲染）——解决「资源获取与导航准备」。工程编排：时机——首屏资源 preload（随 HTML 或首屏 JS 声明）、下一跳应用在「空闲期 prefetch」（requestIdleCallback 或首屏完成后）、高频入口「悬停/进入视口即预取」（用户意图预测）；优先级——「当前应用资源 > 下一应用入口 > 深层资源」，同优先级按体积排序；成本控制——预取不是越多越好：限制预取体积与并发（与首屏关键资源抢带宽会伤害首屏）、预取命中率纳入指标（命中率低说明策略失效需调整）、避免「预取重复」（框架与浏览器层都预取同一资源时去重）。优化收益度量：切换耗时（预取后命中场景的加载时间对比）、首屏不受影响（预取不与关键路径争资源）。微前端特点：预加载「入口 + 核心 chunk」收益最高（切换等待的主要成本），完整子应用预取（全量资源）谨慎使用（成本高）。

回答按「preload/prefetch 语义 → 两层预加载（框架级 + 浏览器级）→ 编排（时机/优先级/成本）→ 收益度量」组织，核心是「预加载是投资，要按命中率与关键路径保护评估」。

• 子应用独立 SSR 的模型：基座组装 vs 子应用自渲染
• SSR 与微前端的冲突点：共享状态、水合、时序
• 现代实践：边缘 SSR、流式渲染与联邦协同

两种模型：基座组装式——基座 SSR 时按激活路由把子应用的「SSR 产物（HTML 片段）或 SSR 服务」嵌入（子应用可独立 SSR 服务，基座聚合）；子应用自渲染式——每个子应用自己 SSR 完整页面，基座只做导航壳（切换时整页级 SSR 或跳转）。工程边界：双端一致性——SSR 输出与客户端水合必须同一份依赖实例与状态（React 的 hydrate 要求服务端与客户端渲染结果一致，共享依赖双实例会导致水合失败）；时序——子应用 SSR 数据获取（服务端数据）与客户端数据同步（序列化状态注入页面）；样式——SSR 输出的 CSS 提取与内联（避免 FOUC 与重复注入）；错误——某子应用 SSR 失败时「降级为客户端渲染该片段」（部分降级），不拖垮整页。现代实践：边缘 SSR——子应用 SSR 下沉到边缘（Edge Runtime），靠近用户降低 TTFB，主应用在边缘聚合多个子应用片段；流式渲染——按子应用片段的就绪顺序流式输出（先就绪先显示），避免「最慢子应用拖累整页 TTFB」；与联邦协同——MF 的 SSR 支持（服务端加载远程模块）+ 共享依赖在服务端同样 singleton；状态串行化——SSR 序列化的状态（server state → client）与共享状态层（globalState）对齐，水合后无缝接管。工程要点：SSR 预算与超时（子应用 SSR 慢不阻塞整页）、缓存（子应用 SSR 结果缓存策略）、「SSR 质量即首屏质量」的监控（TTFB 分段、水合成功率的归因到子应用）。

回答按「两种 SSR 模型 → 工程边界（双端一致、时序、降级）→ 现代实践（边缘、流式、联邦）→ 监控治理」组织，核心是「子应用独立 SSR 的难点在『组合时序与双端一致』，解法是片段化与流式化」。

• 错误分层：子应用内边界、基座全局边界与未捕获兜底
• 崩溃降级：区域占位、重试与恢复
• 策略要点：归属、上报、监控与恢复编排

分层设计：第一层——子应用内错误边界（渲染错误就地降级到占位 UI，不扩散）；第二层——基座全局捕获（未捕获异常、unhandledrejection 由基座统一拦截：记录、归属、必要时整页兜底）；第三层——兜底页（基座自身也挂了的「完全降级」）。崩溃降级的工程策略：区域化——崩溃的子应用区域替换为「占位组件」（含错误提示与重试按钮），页面其他区域（导航、其他子应用）保持可用——「单应用崩溃不影响整体」是微前端核心承诺，降级设计让承诺可视化；重试与恢复——占位提供「重试加载」与「定时自动探测恢复」（后台重新加载子应用，成功后替换占位），恢复要防「恢复风暴」（多个子应用同时崩溃时阶梯式重试）；降级链路——加载失败（entry 超时/资源 404）与运行崩溃（渲染/逻辑错误）分别处理：加载失败走「重试 + 缓存降级（用上次缓存的版本）」，运行崩溃走「边界替换 + 上报」。工程要点：归属——崩溃事件带应用标识与版本（谁崩了、哪个版本崩的）；上报——降级事件全量上报（崩溃率、降级时长是核心指标）；监控——「子应用崩溃率」与「降级恢复率」纳入 SLO，崩溃率突增触发告警与回滚；测试——故障注入演练（模拟崩溃验证降级路径有效）。核心认知：错误处理的目标不是「不崩」，而是「崩了可感知、可恢复、可归属」。

回答按「错误分层（边界/全局/兜底）→ 降级策略（区域占位、重试、恢复防风暴）→ 治理（归属、监控、演练）」组织，核心是「降级是微前端故障隔离承诺的体验化落地」。

• 两种发布模型：统一发布（全量同版本）vs 独立发布（各自节奏）
• 版本管理的载体：版本矩阵、配置中心与快照
• 发布协调的决策：变更耦合度与团队规模

统一发布：所有子应用与基座「同版本同发布」——版本号全局一致、发布动作一次完成；价值是「组合确定性强」（线上永远是某个测试过的全量组合，无版本漂移问题）、验收简单（一次联调一次上线）；代价是「发布节奏被最慢团队绑架」（任何子应用的阻塞都拖累全体）、变更风险全量暴露（一次发布包含大量变更，回滚是全局回滚）。独立发布：各子应用按自身节奏发布——版本各自管理，基座通过配置中心指向各子应用的版本入口，形成「版本矩阵」；价值是「节奏自主」（团队独立迭代、快速上线）、「风险局部化」（单应用发布影响面小、可单独回滚）、「规模扩展」（数百人团队无需全员同步）；代价是「组合验证成本」（线上是各版本的自由组合，需契约测试与组合冒烟保证任意组合可用）、「矩阵治理复杂」（版本漂移、兼容矩阵维护）。决策框架：变更耦合度——跨应用联合变更（契约破坏、共享升级）需要「联合发布窗口」（临时统一发布）；团队规模——小团队/低并发用统一发布简单直接，大规模/高并发独立发布是必然；治理配合——独立发布必须配套「版本矩阵 + 契约测试 + 组合冒烟 + 配置级回滚」，否则「自由」变成「失控」。工程价值判断：独立发布是微前端的「收益来源」之一（自治与速度），统一发布是「治理手段」（确定性），现代工程以「独立发布为主、联合窗口为辅」。

回答按「两模型的价值与代价 → 版本矩阵与配置中心的载体 → 决策框架（耦合度、规模、治理配套）」组织，核心是「独立发布换自治速度，统一发布换确定性，按耦合度与规模权衡」。

• 四种方案的隔离机制分层：约定/构建/运行时/浏览器
• 各方案的强度、成本与兼容性
• 组合选型的工程逻辑

四种方案按「隔离强度的来源」分层：BEM——命名约定（块-元素-修饰符让类名语义化唯一），零成本零工具，但「靠人遵守」只能降低冲突概率不能消除（且对历史代码无效）；CSS-in-JS——构建/运行时生成哈希类名 + 唯一标识，作用域化天然（自研组件样式不冲突），代价是运行时成本与「只约束自己」（第三方库样式仍全局）；qiankun scoped css——运行时改写选择器加容器前缀，解决「存量代码与第三方样式」的隔离（对历史包袱有效），代价是「字符串级改写」有语法覆盖边界（@media/@font-face 等）且动态样式要补丁；Shadow DOM——浏览器原生封装，隔离最彻底（样式与 DOM 双边界），代价是「穿透与适配」（::part/::slotted、全局继承、依赖全局样式的库失效）。工程取舍：没有「最好」，只有「匹配场景」——自研新代码用 CSS-in-JS/CSS Modules（构建期作用域化）；存量与第三方代码用 qiankun scoped（运行时兜底）；强边界场景（第三方嵌入、敏感样式）用 Shadow DOM；BEM 作为「跨方案的基础纪律」（即使有工具，命名规范仍降低协作成本）；微前端实践通常是「组合拳」：构建期哈希（自研）+ 运行时 scoped（存量）+ shadow（特殊场景），并按「子应用对全局样式的依赖度」选择强度。

回答按「四方案机制分层（约定/构建/运行时/浏览器）→ 强度与成本对比 → 组合选型逻辑」组织，核心是「隔离强度与兼容成本成正比，工程上是组合而非单选」。

• 两种方案的定位差异：应用编排 vs 模块共享
• 通信与依赖共享的实现差异
• 版本冲突的处理机制与组合实践

定位差异：micro-app 是「应用编排框架」（子应用加载、隔离、生命周期、通信），MF 是「模块共享机制」（运行时共享依赖与远程模块）——两者解决不同问题，工程上常组合（micro-app 管应用、MF 管共享）。通信：micro-app 提供基于 CustomEvent 的组件化通信（元素事件 + 数据传递），基座与子应用通过事件/属性交互，模型贴近 Web Components；MF 本身不提供「应用间通信」语义（它是模块加载），通信靠业务自建（事件总线、共享状态、props 化远程组件）。依赖共享：micro-app 的依赖共享靠「构建策略」（子应用 external 公共依赖由基座提供全局或通过配置共享）——运行时无版本协商，依赖「构建约定」一致；MF 的 shared 提供「运行时协商」（requiredVersion/singleton 版本匹配、复用或自载）。版本冲突：micro-app 模式——共享依赖版本不一致时「没有自动协商」，靠构建配置与团队约定（版本对齐清单），冲突表现为「运行时不兼容」（双实例、API 差异），发现晚；MF 模式——冲突在「加载时协商」显性化（告警/报错/strictVersion），发现早、可治理。工程取舍：应用编排 + 事件通信的「组件化体验」选 micro-app；「依赖共享的运行时治理」选 MF（或两者组合：micro-app 编排 + 关键共享依赖走 MF）；版本冲突治理角度，MF 的协商机制比「构建期约定」更可靠。

回答按「定位差异（编排 vs 共享）→ 通信与共享实现对比 → 版本冲突的显性化程度 → 组合实践」组织，核心是「micro-app 管应用怎么跑，MF 管依赖怎么享，冲突治理是 MF 的强项」。

• 两种 API 的语义：声明式注册 vs 命令式加载
• 按需加载与全量注册的运行时差异
• 现代工程中的应用场景与选型

registerMicroApps——声明式「全量注册」：启动时把全部子应用注册进路由表（appName + activeRule + entry），基座按路由自动激活；价值是「托管式」——激活/卸载/生命周期全自动、路由驱动清晰（传统微前端架构的骨架），代价是「全量注册」意味着路由表全量（配置集中、启动信息全量加载——注册本身轻量但「注册即声明」的治理模式）；loadMicroApp——命令式「按需加载」：在需要时手动加载一个子应用实例到指定容器（可手动挂载多个实例）；价值是「灵活」——不受路由约束的嵌入场景（dashboard 拼装、组件化嵌入、同页多实例）、运行时动态注册（远程下发的应用配置）、精细控制（何时加载、挂到哪个容器、手动卸载）。现代工程价值：混合使用——「核心路由应用 registerMicroApps 托管 + 非路由/动态场景 loadMicroApp」；loadMicroApp 支撑「应用作为组件」的模式（微前端从「页面级」下沉到「组件级嵌入」）；按需价值——首屏只注册/加载必要的应用（注册表按需构建），动态应用（从配置中心拉取注册表）降低「全量注册」的集中治理成本；注意点——loadMicroApp 手动管理生命周期（要自己处理卸载与清理），多实例时内存与沙箱成本上升。

回答按「两 API 语义（声明式注册 vs 命令式加载）→ 场景差异（路由托管 vs 动态嵌入）→ 现代组合（核心托管 + 动态按需）」组织，核心是「托管式保结构、命令式保灵活，按场景组合」。

• 两种模式的架构语义：统一基座 vs 无基座分散
• 团队协作与发布节奏的差异
• 模式选择的边界条件

基座-子应用模式：有统一基座（导航壳、鉴权、路由、公共能力），子应用注册进基座协作——协作上有「统一入口与统一治理」（平台团队维护基座，子应用团队按契约接入），发布节奏「子应用独立 + 基座低频演进」（基座是公共变更点，升级影响所有子应用，需兼容窗口）；边界是「基座成为瓶颈」（基座改动需要全生态验证、基座故障影响所有应用）。完全独立模式：无统一基座（每个应用自给自足，页面间通过 URL/服务端组合），协作上「无公共变更点」（团队间无运行时依赖，只有契约依赖），发布节奏完全自主（互不阻塞）；边界是「体验一致性靠约定」（导航、主题、鉴权每个应用自己实现，易分叉）、「跨应用流程的编排成本」（跳转与数据传递靠 URL/协议，复杂交互体验受限）。选择边界：组织规模与协作密度——小团队/低跨应用交互可用完全独立（简单直接），多团队/需要统一体验与共享能力（统一鉴权、统一导航、统一主题）必须基座模式；演进阶段——早期「完全独立 + 服务端组合」起步，交互复杂化后演进出「基座」；「基座胖瘦」的平衡——基座只做「公共能力与治理」不承载业务（业务下沉子应用），避免基座变成新的巨石。工程判断：两种模式是「连续谱」而非二选一——基座的程度（导航/鉴权/壳/公共库）按「公共性」逐层决策。

回答按「两模式的架构与协作差异 → 发布节奏（基座低频 vs 全自主）→ 选择边界（规模、体验、演进）」组织，核心是「基座的边界由公共性决定，模式是连续谱」。

• 两种 entry 模式的机制：HTML 全量解析 vs JS 入口
• 首屏速度的差异来源：资源发现与解析成本
• 现代构建（联邦/ESM）下的演进取舍

HTML Entry（micro-app、qiankun 默认）：加载子应用入口 HTML，解析出模板/样式/脚本后注入——优势是「灵活」（子应用可用任何构建方式，甚至非构建产物，天然兼容存量）；首屏代价是「额外一轮解析与注入」：fetch HTML → 解析资源列表 → 改路径 → 按序注入执行，且 HTML 内的脚本依赖顺序执行（同步等待）拉长「子应用资源就绪」时间，资源发现是「链式」（先 HTML 后 chunk），并行度受限。entry JS 模式（qiankun 的 entry 配置为 JS、MF 的 remoteEntry）：基座直接加载子应用的 JS 入口（构建产物）——资源发现直接（入口 JS 即起点）、无 HTML 解析成本、脚本按构建期拆分（现代打包的按需 chunk 自然并行加载）；代价是「要求子应用有构建产物」且「入口契约强」（入口文件必须暴露生命周期/注册信息），对存量（无构建的 HTML 应用）不友好。现代构建的取舍：现代工程（Vite/webpack 5+）产物已是「入口 JS + 按需 chunk」结构，entry JS 模式与构建体系天然匹配（联邦 remoteEntry 即此模式）——首屏更快、加载可并行；HTML Entry 保留给「存量系统接入」（无法快速改造的旧应用）——首屏成本可接受（存量接入优先正确性）；演进方向——「HTML Entry 兼容存量 + 现代子应用走 entry JS/联邦」，双模式并存（micro-app 也支持 JS entry 配置）。首屏速度关键差异：解析轮次（HTML 多一轮）与加载并行度（链式 vs 直接），现代构建下 entry JS 模式通常更快。

回答按「两模式的机制与首屏成本差异（解析轮次、并行度）→ 现代构建的匹配度（entry JS 契合、HTML 兼容存量）→ 双模式演进」组织，核心是「entry 模式的选择是『存量兼容』与『现代性能』的权衡」。

• 三配置的语义：提供、消费、共享
• 大型工程的配置治理：目录化、命名与版本
• 实践要点：契约、边界与故障面

三配置语义：exposes——「本应用对外提供什么」：把模块暴露为远程可加载（模块名 + 路径映射），是「提供方契约」；remotes——「本应用消费谁的什么」：声明远程来源（remoteName: entry 地址），是「消费方引用」；shared——「本应用希望共享什么」：声明公共依赖的共享策略（版本、singleton），是「协作基线」。大型工程实践：exposes 治理——暴露面「最小化 + 契约化」：只暴露「稳定接口」（业务模块、共享组件）而非内部实现，模块命名全局唯一（应用前缀），导出类型随版本契约管理（契约测试校验）；remotes 治理——远程地址「配置化」：入口地址不写死（走配置中心/环境变量，支持灰度与回滚），远程来源「收敛」：消费方不直接写远程地址而是引用「平台维护的远程目录」（统一入口版本）；shared 治理——共享清单「平台统一」：哪些依赖共享、版本策略（requiredVersion 范围、singleton）由平台模板下发，避免各团队各自决策导致协商混乱；故障面控制——「远程依赖分级」：核心链路远程（UI 框架、公共组件）高可用治理（降级、缓存），远程不可用时消费方「容错」（本地 fallback、错误 UI）；可观测——远程加载与共享协商的指标（成功率、协商结果）统一采集。工程要点：三配置构成「模块拓扑」——大型工程用「拓扑文档 + 校验工具」（CI 校验 exposes 是否被消费、remotes 是否可达、shared 版本是否冲突），把「配置正确性」从运行时问题前置为 CI 问题。

回答按「三配置语义（提供/消费/共享）→ 大型工程治理（目录化、配置化、平台模板）→ 故障面与可观测 → 拓扑校验」组织，核心是「三配置是联邦的契约面，大型工程把契约治理前置到 CI」。

• Vite 5+ 与 Rspack 的联邦支持方式
• dev 与 build 模式的联邦行为差异
• 迁移与混用注意点

支持方式：Vite 生态经 @module-federation/vite（或 enhanced 的 Vite 插件）获得联邦能力（Vite 5+ 的插件适配更成熟）；Rspack 提供原生 ModuleFederationPlugin（配置与 webpack 对齐）。dev 与 build 差异：Vite dev 模式基于原生 ESM + 中间件——联邦在 dev 通过「插件 + dev server 的模块重写」实现（远程模块在 dev 下以 ESM URL 加载），与 webpack dev 的运行时注入不同，需单独验证 dev 联调场景（热更新、远程模块刷新）；build 模式产出 remoteEntry 与 chunk，与 webpack 产物的互操作依赖「联邦运行时兼容」（2.0 独立 runtime 支持跨构建器）。注意点：共享依赖格式——Vite 的 ESM 产物与 webpack 的 chunk 格式在共享依赖（shared）上要由运行时统一包装（版本协商语义一致）；dev 远程加载——Vite dev 下远程应用必须也跑 dev server（或特殊配置），否则远程 URL 指向不存在的产物；类型与契约——跨构建器的远程类型仍靠「契约文件/声明」维护；迁移路径——webpack MF 工程迁 Vite/Rspack：配置等价映射（exposes/remotes/shared 语义一致）+ 联邦契约测试（迁移后协商与加载行为回归）；混用架构——「构建器异构」（部分应用 webpack、部分 Vite/Rspack）在大型组织常见（团队自主选型），依赖「统一联邦运行时 + 契约层」保证互操作；Vite 特定——import.meta 相关代码、worker 加载、CSS 处理的产物差异要纳入联邦产物验证。工程建议：新项目优先 Rspack/Vite 原生或增强插件（性能与生态），存量 webpack 联邦按「契约测试 + 灰度」迁移。

回答按「支持方式（插件/原生）→ dev 与 build 差异 → 共享与互操作注意点 → 迁移与混用策略」组织，核心是「构建器异构下联邦的正确性靠统一运行时与契约测试保障」。

• 大规模团队的协作特征：多团队并行、节奏差异
• 独立部署与联合发版的适用边界
• 大规模治理：契约、灰度、回滚与协调机制

大规模团队（数百人、数十个应用）的核心矛盾是「并行度 vs 一致性」：独立部署——每个团队按自己节奏发布，并行度最高（互不阻塞），工程前提是「契约边界足够硬」（接口、共享依赖、样式、事件都有契约测试保护，任意组合可用）与「故障隔离可靠」（单应用事故不扩散，配置级回滚秒级）；否则「自由」演变为「组合失控」（线上是未验证的版本组合）。联合发版——全体（或相关组）同步发布，一致性最强（组合确定），但「数百人的发布协调」成本极高（窗口对齐、等待最慢团队），频率必然低（周级甚至更低），与「快速迭代」冲突。大规模协作的边界判断：按「变更影响面」分流——「局域变更」（单个子应用自身功能）走独立部署（占绝大多数，保持速度）；「跨域变更」（契约破坏、共享依赖升级、基座改动）走「联合窗口」（低频、集中、全量验证）；治理配套：版本矩阵与兼容承诺（子应用承诺对基座 N-1 兼容）、契约测试进 CI（跨团队破坏自动拦截）、灰度与回滚基础设施（组合级灰度、矩阵快照回滚）、「发布日历」协调机制（预占窗口、冲突检测）；组织机制——「平台/架构委员会」治理公共契约变更，团队 self-service 走独立发布——「制度把变更分级，基础设施把分级落地」。

回答按「大规模协作的矛盾（并行 vs 一致）→ 分流边界（局域独立、跨域联合）→ 治理配套（契约、矩阵、日历）」组织，核心是「大规模微前端的工程边界 = 把变更分级 + 用基础设施落地分级」。

• JWT 与 Cookie 两种凭据模型的传递方式
• 主子应用的 Session 同步：登录、刷新、登出
• 安全要点：存储、跨域与失效

JWT 模型：基座统一获取与刷新 JWT（登录、静默刷新），通过受控通道（props 注入、沙箱内暴露）下发给子应用，子应用请求时携带（Authorization 头）；跨域子应用场景 JWT 传递注意「不在 URL/明文存储广播」（防泄露），刷新由基座统一触发并广播（子应用收到新 token 更新内存）。Cookie 模型：HttpOnly Cookie 由浏览器自动携带，主子应用「同域」时天然共享（无需传递代码）；跨子域用 SameSite=None + Secure（或 SameSite=Lax 下同站共享），第三方 iframe 场景受浏览器策略限制（需 Storage Access API 或显式桥接）。Session 同步策略：登录——基座完成认证后广播「登录完成」事件 + 下发用户信息/token，子应用同步初始化；刷新——token 过期前基座静默刷新（refresh token），新 token 广播同步；登出——基座触发登出（清 token、跳登录页）并广播「登出」事件，子应用清理本地会话（缓存、内存凭据），防止「已登出但子应用仍持有会话」的越权窗口；会话失效——token 过期时子应用请求 401，统一走「刷新失败 → 重新登录」流程（避免各子应用各自跳登录页的混乱）。安全要点：凭据最小暴露（子应用只拿「调用所需」的 token 而非全部权限凭据）、跨域信任（子应用信任分级，低信任应用不授予完整凭据）、审计（token 生命周期与使用记录）。工程要点：「鉴权 SDK 统一」（基座提供，子应用消费契约），Session 状态作为共享状态（globalState 切片）供子应用订阅。

回答按「JWT/Cookie 两种模型的传递 → Session 生命周期同步（登录/刷新/登出/失效）→ 安全要点」组织，核心是「鉴权传递的统一与 Session 同步的广播契约」。

• import-html-entry 的执行模型：运行时注入并执行内联/远程脚本
• 严格 CSP 下的冲突：script-src、nonce、unsafe-eval
• 与现代联邦的差异：解析时机、产物结构与策略友好度

冲突根源：import-html-entry 把远程 HTML 中的脚本「运行时注入页面执行」——内联脚本执行违反「无 unsafe-inline」的 script-src、动态 script 创建要求来源白名单、with + eval 的沙箱执行要求 'unsafe-eval'——严格 CSP（无 unsafe-inline/unsafe-eval）下这些行为被直接拦截，子应用无法加载。边界的处理：nonce 化——服务器响应为注入的脚本动态生成 nonce（运行时注入者拿不到响应 nonce，实际工程中需要「脚本内联到 HTML 时带 nonce 或走非内联通道」）；白名单化——远程脚本 URL 加入 script-src 域名白名单（可行，但要收敛域名）；沙箱与 unsafe-eval——沙箱的 eval 依赖与严格 CSP 直接冲突，需「无 eval 沙箱」（代码改写式）或接受放宽；替代路径——把「运行时解析 HTML 注入脚本」改为「构建产物直连」（子应用产物按 CSP 友好方式组织：外部脚本 + 明确域名 + 无内联）。与现代联邦的差异：解析时机——qiankun 运行时解析（每次加载解析 HTML、注入执行），webpack/Vite 联邦构建期产物（remoteEntry 是 JS 模块图，加载即标准脚本执行，无 HTML 解析与内联注入）；CSP 友好度——联邦产物的「标准脚本 + 明确来源」天然符合严格 CSP（无内联执行、无 eval 依赖），qiankun 的「注入执行」模型与严格 CSP 存在结构性冲突；产物结构——联邦的 chunk 自带 hash 与依赖图，加载即浏览器原生语义，qiankun 的 HTML 资源发现是「链式解析」；现代取舍——严格安全要求的工程倾向「联邦/JS entry」模式（CSP 友好），qiankun HTML entry 保留给「存量兼容 + 安全要求不极端」的场景。

回答按「冲突机制（注入执行 vs script-src/eval）→ 边界处理（nonce、白名单、无 eval 沙箱）→ 与现代联邦的差异（解析时机、CSP 友好度）→ 工程取向」组织，核心是「执行模型决定 CSP 友好度：联邦的构建产物模型天然严格化，HTML 注入模型与严格 CSP 结构冲突」。

• 四种框架的 entry 形态：JS 契约 / HTML / 元素配置
• 激活策略：activeWhen/activeRule/URL 匹配/手动挂载
• 按场景的取舍逻辑

entry 形态：single-spa——JS 契约入口（子应用构建产物暴露 bootstrap/mount/unmount，基座注册时给 entry URL）；qiankun——默认 HTML Entry（import-html-entry 运行时解析），也支持 JS entry；micro-app——元素配置（ ，框架加载远程 HTML 注入元素），本质 HTML Entry + 元素化；wujie——HTML Entry（加载远程 HTML 到 iframe 执行 + DOM 搬到容器）。激活策略：single-spa——activeWhen（路径前缀/函数），路由驱动；qiankun——activeRule（前缀/函数/正则），路由驱动 + loadMicroApp 手动；micro-app——元素挂载即激活（页面里放了 就加载），URL 属性变化可切换应用（声明式 + 部分路由联动）；wujie——元素挂载 + URL 同步（iframe 内独立路由与基座 URL 桥接），激活由「元素存在 + 路由同步」共同决定。工程取舍：契约规范——single-spa/qiankun 要求「子应用暴露生命周期」（强契约、可控），micro-app/wujie 更「声明式」（低门槛接入，契约隐藏）；激活模型——「路由驱动」适合「页面级应用切换」（传统微前端），「元素/手动驱动」适合「组件级嵌入与同页多实例」（dashboard 拼装）；学习与生态——single-spa 最底层灵活（自己组装）、qiankun 生态最成熟（问题沉淀多）、micro-app/wujie 新且体验友好（文档与社区较新）；选择逻辑：要「最标准最灵活」用 single-spa 自组、要「成熟托管」用 qiankun、要「低门槛元素化」用 micro-app、要「强隔离 + 元素体验」用 wujie。

回答按「entry 形态对比（JS 契约/HTML/元素）→ 激活策略对比（路由/元素/手动）→ 场景取舍」组织，核心是「entry 与激活模型决定接入门槛与控制力，按团队能力与场景选型」。

• 路由变化 → 激活判定的执行模型（事件驱动/监听）
• 生命周期调用的时序与并发模型
• 框架间的实现差异：single-spa 队列、qiankun 编排、wujie 桥接

通用模型：基座监听路由变化（history/hash 事件）→ 重新计算激活集合（哪些应用命中）→ 对「新命中未加载」的触发 bootstrap + mount、对「不再命中」的触发 unmount——执行模型的关键是「时序与并发」。single-spa：集中式「导航队列」——路由变化触发 reroute 流程，生命周期调用「串行化」：卸载旧集合（按序 unmount）、挂载新集合（按序 mount），Promise 串行等待保证「同一时刻最多一个过渡」；子应用激活判定由注册的 activeWhen 在每次导航时求值。qiankun：基于 single-spa 的 reroute，叠加「全局状态（globalState）」与「加载缓存」——首次激活时加载 entry + bootstrap，后续激活直接 mount；提供 loadMicroApp 的「手动模型」（绕过路由队列直接挂载）。wujie：激活由「元素 + URL 同步」驱动——基座路由变化通过「路由同步机制」反映到 iframe（子应用自己处理内部路由），子应用「在 iframe 内自行渲染」，基座侧主要是「元素挂载/隐藏」而非「生命周期调度」（mount/unmount 语义弱化为显隐 + 状态同步）；执行模型差异的本质：single-spa/qiankun 是「主线程生命周期调度」（基座完全控制何时调用），wujie 是「iframe 自治 + 基座桥接」（子应用自控渲染，基座控制容器）。工程影响：调度模型决定「切换的原子性」（single-spa 队列保证不并发，手动模型需自己防竞态）与「错误隔离」（调度失败在基座层兜底 vs iframe 内自治）；选型时关注「切换过渡的精细控制」需求——需要严格编排用 single-spa/qiankun，接受「容器级显隐」用 wujie。

回答按「通用模型（路由 → 激活 → 生命周期）→ 各框架执行模型（队列串行 / 托管编排 / iframe 自治）→ 工程影响」组织，核心是「执行模型决定切换的原子性与控制力」。

• 契约的载体：类型、schema、协议文档与运行时校验
• 独立部署下的漂移场景：基座旧 vs 子应用新、子应用回滚
• 防漂移机制：契约测试、兼容矩阵与门禁

契约约定：基座与子应用间的接口（props 参数、事件协议、共享状态字段、路由契约、暴露的 API）「显式化 + 版本化」——单一来源（契约仓库生成类型与 schema）、版本号管理（major 变更 = breaking）、文档化（谁提供谁消费）；运行时校验（开发环境对 props/事件 payload 校验）作为兜底。漂移场景：子应用升级使用新契约字段、基座未升级（基座旧）——子应用读不到新字段；基座升级、部分子应用未升级（子应用旧）——基座传了新字段旧子应用忽略（兼容）或旧子应用缺失新行为（破坏）；子应用回滚——回滚版本与基座版本的契约是否仍成立（回滚前校验）。防漂移机制：契约测试——消费者基于契约生成 stub 验证提供方实现（Pact 式），独立 CI 中「基座契约 vs 子应用实现」「子应用契约 vs 基座实现」双向验证，任何一端破坏即阻断发布；兼容矩阵——「基座版本 × 子应用版本」的支持组合显式维护，发布时按「将要上线的组合」执行集成冒烟；兼容策略——「前后兼容窗口」（新版本契约同时支持新旧字段，旧版本在窗口期内不受影响），breaking 变更走「联合发布窗口」；门禁与监控——契约版本比对进 CI 门禁（不匹配不放行）、运行时契约违规（字段缺失/类型错误）上报监控，把「漂移」从「线上事故」变为「发布前拦截 + 运行时告警」。

回答按「契约显式化（载体与版本）→ 漂移场景枚举 → 防漂移机制（双向契约测试、兼容矩阵、门禁监控）」组织，核心是「防漂移 = 契约版本化 + 双向验证 + 兼容窗口」。

• 路由级按需：激活才加载，切换成本与首屏的取舍
• 组件级按需：子应用内重型组件的懒加载
• 平衡手段：预加载、预算门禁与优先级

路由级按需（应用粒度）：子应用「激活才加载」——首屏只加载「当前路由涉及的子应用」资源（资源预算最优：不激活不加载）；代价是「切换成本」：激活时现场加载（首屏/切换体验受网络影响）。组件级按需（模块粒度）：子应用内部的「重型组件懒加载」（图表、编辑器、弹窗模块）——首屏只渲染「可见部分」的代码；代价是「交互时等待」（首次打开重型组件有加载延迟）。平衡的核心是「把加载时机从『需要时』提前到『空闲时』，把预算花在刀刃上」：预加载编排——首屏关键路径的资源 preload、下一跳子应用「空闲 prefetch」（requestIdleCallback 调度）、高频入口「意图预取」（悬停/靠近即拉）；预算门禁——「激活路径总量」预算（首屏 ≤ 阈值），子应用体积配额（超限 CI 拦截），组件级懒加载的「收益评估」（拆了但首屏用不到 → 无效拆分）；优先级——「当前应用关键资源 > 下一应用入口 > 深层组件」，同层按体积排序；体验兜底——按需加载的「加载态设计」（骨架屏、进度反馈）让等待可感知；「渐进加载」——先框架壳后数据（首屏快），交互密集区（图表）后加载。工程判断：路由级按需是「预算正确性」的基础（不激活不加载），组件级按需是「体验精细化」的手段，预加载是「平衡器」——三者的配置以「激活路径实测」为决策依据。

回答按「两级按需的机制与代价 → 平衡手段（预加载、预算门禁、优先级）→ 体验兜底」组织，核心是「按需保预算、预加载补体验、预算门禁保底线」。

• 独立 CI 的流水线模型与门禁
• 独立灰度的维度：应用级、版本组合级、用户级
• 回滚策略：产物级、配置级、组合快照

独立 CI 范式：基座与每个子应用「独立流水线」——各自构建、各自门禁（质量、体积、契约、安全扫描）、各自产物归档（版本目录 + 清单）；跨应用验证在「集成阶段」而非「构建阶段」：契约测试（独立跑，任一破坏即阻断本端发布）+ 组合冒烟（发布候选在预发组合环境验证）。独立灰度：应用级——单个子应用按用户/流量灰度（1% → 10% → 100%），入口配置切换（灰度组指向新版本目录）；组合级——「基座新 + 子应用新」等多版本组合同时灰度（灰度矩阵：不同用户组见不同组合）；用户级——按用户分桶保证「同一用户稳定见同一组合」（避免用户在同一次会话内组合跳变）；灰度观测——按「桶 × 版本」对比错误率、性能与业务指标。回滚策略：产物级——回滚 = 配置中心把入口指回旧版本目录（秒级，无需重新构建）；组合级——「版本矩阵快照」整体回退（基座与相关子应用同时切回上一快照，避免「只回滚一个留下混合状态」）；边界——「数据前滚」问题（新版本写入的数据旧版本能否读）、「缓存残留」（CDN/浏览器缓存旧入口，回滚后要按版本清理）、「契约兼容」（回滚后的组合必须契约成立——回滚前用兼容矩阵校验）；回滚流程：自动回滚阈值（指标异常自动触发）与手动回滚（人工决策）结合，回滚动作全程审计并保留「事故复盘数据」（灰度期日志）。

回答按「独立 CI 模型（独立流水线 + 跨应用验证前置）→ 独立灰度维度（应用/组合/用户）→ 回滚策略（产物/组合快照）与边界（数据、缓存、契约）」组织，核心是「独立发布的价值靠『配置驱动的灰度回滚』兑现，回滚是组合级的而非单点」。

• SSR/SSG 与微前端的组合形态：基座 SSR + 子应用渲染策略
• 子应用预渲染（服务端输出片段）与客户端水合的对接
• 架构约束：共享状态、依赖单例、样式与时序

组合形态：基座 SSR/SSG——基座在服务端渲染壳（导航、布局、全局状态），子应用按「渲染策略」二选一：预渲染（子应用也服务端渲染，输出 HTML 片段嵌入基座输出）或客户端渲染（基座输出占位，客户端加载子应用水合/渲染）。架构约束：双端一致性——预渲染的子应用「服务端输出与客户端水合必须同一份状态与依赖」（React hydrate 要求 DOM 匹配，共享依赖双实例导致水合失败）；状态序列化——服务端渲染的状态（数据、用户、路由）要「序列化注入页面」供客户端接管（window.INITIAL_STATE），子应用状态与基座状态分开序列化、水合后合并；依赖单例——SSR 期间共享依赖（框架）必须单例（服务端进程内多应用共享），与浏览器端 singleton 策略一致；样式——预渲染的 CSS 提取与注入（避免 FOUC），子应用样式在 SSR 产物中管理；时序——「SSR 数据获取 vs 客户端数据获取」的一致性（服务端拉过的数据客户端不重复拉）；降级——子应用 SSR 失败时「降级为该片段客户端渲染」（部分降级，不拖垮整页）；SSG——预构建时全量预渲染（适合低动态内容），动态内容子应用用「客户端水合 + 增量」策略；架构约束的本质：SSR/SSG 把「运行时组合」变成「渲染期组合」——子应用的服务端渲染能力（框架 SSR 支持、数据获取、样式）成为接入前提，工程上「子应用 SSR 能力分级」（必须支持预渲染 / 允许仅 CSR）在接入清单中显式声明。

回答按「组合形态（基座 SSR + 子应用预渲染/CSR）→ 约束（双端一致、状态序列化、单例、降级）→ SSG 与能力分级」组织，核心是「SSR 微前端的难点是把运行时组合提前到渲染期并保证双端一致」。

• 各配置项的语义与组合矩阵
• 版本不满足时的运行时行为分支：复用/自载/告警/报错/eager 破坏
• 组合的工程含义

配置组合的行为矩阵（以宿主 React 18、远程要求 React 19 为例）：shared + singleton: false + requiredVersion 不满足——远程「自载自己的 19」（多副本共存），行为正常但体积膨胀、若为框架依赖则双实例风险（invalid hook call）；shared + singleton: true + requiredVersion 不满足——远程「降级复用宿主 18」+ 控制台告警（版本不满足但仍单例运行，保证不双实例）；shared + singleton: true + strictVersion: true + 不满足——「加载报错」（Error: Shared module version mismatch），联邦运行时拒绝加载远程模块，强制解决版本问题；shared + eager: true——远程构建时「把 React 打进入口 bundle」并在共享作用域「立即注册」，跳过「异步加载后再注册」的步骤：若宿主先加载且 eager 的远程先注册了旧版本，宿主加载时协商可能被旧版本「抢占」（版本不满足时宿主自载或按策略降级）；eager 的本质影响——共享依赖「提前到入口加载」，破坏「异步共享边界」（共享模块应该在异步 chunk 加载时注册，eager 让它在入口同步注册），版本协商的「时机」被改变，宿主与远程「谁先注册」决定协商结果，出现「版本满足但行为与预期不同」的隐性组合问题。工程含义：框架类依赖用 singleton + 合理 requiredVersion（宽范围）保障「不双实例」；strictVersion 用于「版本不一致 = 高风险」的场景（让问题加载期显性化）；eager 只用于「明确要打进入口的少量依赖」（如宿主自身），远程共享依赖避免 eager（破坏协商时序）。

回答按「配置组合的行为矩阵（自载/降级告警/报错）→ eager 的特殊性（提前注册改变协商时机）→ 工程配置建议」组织，核心是「组合决定失败模式：自载、告警或报错，eager 改变协商时序」。

• eager 的语义：依赖同步打包进入口并立即注册
• 破坏异步共享边界：共享注册时机与协商时序
• 入口包放大：体积与首屏成本

eager 的机制：把共享依赖「打进入口 bundle」（不再作为异步 chunk 在共享协商时按需加载），入口脚本执行时「立即把该依赖注册进共享作用域」——它跳过了「远程模块加载后才注册共享依赖」的异步路径。破坏异步共享边界的原理：联邦的共享模型是「异步注册 + 协商」——远程的共享依赖在远程加载时注册，宿主与远程「按加载顺序协商版本」；eager 把注册提前到「入口同步执行」，导致：时序反转——远程入口先执行时，其 eager 的依赖版本「抢先注册」，宿主的协商「被远程版本先入为主」（宿主可能被迫复用远程的版本或自载），「谁先加载谁说了算」的隐性顺序依赖出现；复用失效——本应「按 requiredVersion 协商复用」的依赖因 eager 提前注册而绕过协商（直接可用但版本未必匹配，或匹配但该实例不是预期实例）；边界破坏——「共享依赖在异步边界注册」的设计（保证加载某个远程时才引入其共享版本）被 eager 破坏，多个远程各自 eager 同一依赖时「注册竞争」导致行为不确定。入口包放大：eager 把大型依赖（React 数百 KB）打进每个远程的入口——每个远程都自带一份（即使共享配置了，eager 也强制进入口），共享去重失效、入口体积膨胀、首屏下载量线性增长（N 个远程 N 份 React）；且入口「同步执行大依赖」阻塞首屏解析。工程结论：eager 只应服务于「宿主自身或必须入口同步」的少量依赖（如 polyfill、宿主框架），远程应用的共享依赖保持「异步注册」（默认行为），让协商时序保持确定。

回答按「eager 机制（入口打包 + 立即注册）→ 破坏异步共享边界（注册时序反转、协商绕过、注册竞争）→ 体积放大（每远程一份）→ 工程结论」组织，核心是「eager 用『入口同步』换便利，代价是协商时序与共享去重被破坏」。

• 多技术栈共存的全局污染面：polyfill、自定义元素、样式、事件、devtools
• 隔离机制：按应用边界注入、注册表隔离与补丁快照
• 加载顺序与依赖的治理

污染面与隔离手段：全局 polyfill——各技术栈/库可能注入全局补丁（Promise、Array 方法、事件行为），后加载的覆盖先加载的：隔离用「按应用边界注入」（polyfill 在应用容器/沙箱内注入并随应用卸载清理，或改用「无全局污染的局部实现」）、「先加载先注册 + 版本一致性」（同一 polyfill 强制全应用统一版本）；Custom Elements 注册表——customElements.define 是「全局唯一注册表」，同名元素「后定义覆盖先定义」（不同技术栈定义同名组件时先加载应用的组件被替换）：隔离用「命名空间化」（元素名按应用前缀，如 app1-x-button，注册表全局唯一但名称域隔离）、「冲突检测」（加载前检查名称占用并告警）；CSS reset——后加载应用的 reset 会重置先加载应用的样式：隔离用「reset 收敛」（reset 由基座统一注入且各应用约定不再引入独立 reset）、「作用域化」（应用样式全部 scoped，reset 只作用于应用容器）；事件补丁——框架对原生事件系统打补丁（React 17+ 的 root 级事件委托、Vue 的事件处理），后加载的补丁可能替换先加载的（如全局事件委托根节点冲突）：隔离用「各框架的现代事件模型」（React 的 createRoot 事件委托只在自己 root 内、避免全局 document 级监听冲突）、「统一事件层」（事件监听由基座统一管理）；devtools hook——React/Vue devtools 都抢 window.REACT_DEVTOOLS_GLOBAL_HOOK 等全局钩子，后加载框架的初始化会覆盖先加载的：隔离用「hook 兼容层」（统一 hook 代理，多个框架的 renderer 注册并存）或「生产环境剥离」（devtools 相关代码生产不注入）。系统性治理：多技术栈共存的前提是「每类全局资源的归属与冲突规则显式化」——登记表（谁注入了什么全局）、加载顺序策略（先加载的应用不受后加载影响：冲突时「后加载遵守先加载的约定」或「按应用边界完全隔离」）、以及「全栈共存验证」（组合冒烟测试覆盖加载顺序矩阵）。

回答按「五类污染面逐一给隔离手段（命名空间、作用域、统一层、兼容层）→ 系统性治理（登记表、顺序策略、组合验证）」组织，核心是「多技术栈共存 = 对每类全局资源定义归属与冲突规则 + 组合验证」。