前端面试题手册

Module Federation 的生产部署比普通前端应用多一个关键变量：Host 和 Remote 不一定同时发布。这个能力带来了独立交付，也带来了缓存、版本、回滚和跨域问题。很多线上事故不是代码逻辑错，而是 Host 加载到了旧的 remoteEntry、Remote 静态资源路径不对，或者 CDN 把本该及时更新的入口文件缓存住了。稳妥的部署策略是把 remoteEntry 当成运行时入口，而不是普通静态资源随便缓存。Remote 的 JS、CSS chunk 可以带 hash 长缓存，但 remoteEntry.js 建议短缓存或 no-cache，并通过版本化目录保留历史构建。Host 不要硬编码唯一地址，最好从环境变量或配置中心读取当前可用版本，这样 Remote 回滚时不必重新构建 Host。独立部署的价值，必须靠版本管理和回滚机制兑现。location /remoteEntry.js { add_header Cache-Control "no-cache, no-store, must-revalidate"; try_files $uri =404;}location /assets/ { add_header Cache-Control "public, max-age=31536000, immutable";}new ModuleFederationPlugin({ name: 'host', remotes: { order: `order@${process.env.ORDER_REMOTE_URL}/remoteEntry.js` }, shared: { react: { singleton: true, requiredVersion: '^18.2.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.2.0' } }})Nginx 配置解决缓存边界，Webpack 配置解决运行时地址。这里的取舍是：remoteEntry 不缓存会多一次网络请求，但换来的是发布和回滚可控；chunk 长缓存能降低流量，但前提是文件名带 hash 且旧版本不会立刻删除。Remote 构建产物最好保留最近几版，避免 Host 或用户浏览器还引用旧 chunk 时出现 404。追问remoteEntry.js 应该缓存多久？生产环境通常不建议长缓存 remoteEntry，因为它决定 Host 当前会加载哪些 chunk 和暴露模块。可以使用 no-cache，让浏览器每次校验；如果流量很大，也可以设置很短的 max-age，并配合版本化 URL。取舍是缓存越短，请求越多；缓存越长，发布和回滚越不可控。真正适合长缓存的是带内容 hash 的 chunk 文件，而不是 remoteEntry。Host 和 Remote 谁先部署比较安全？如果是兼容性变更，通常先部署 Remote，再让 Host 使用新能力；如果是破坏性变更，必须先让 Remote 同时兼容新旧契约，再逐步升级 Host。不要让 Host 先调用一个尚未上线的暴露模块，也不要让 Remote 删除旧模块后仍有旧 Host 在访问。边界规则很简单：公开契约至少保留一个灰度周期。踩坑最多的是“本团队已经发版了”，但另一个团队的 Host 还在旧版本。静态资源 publicPath 配错会有什么表现？最常见表现是 remoteEntry 能加载，真正进入页面时 chunk、CSS 或字体 404。因为 remoteEntry 只负责登记模块，后续异步 chunk 还要根据 publicPath 拼地址。可以使用 publicPath: 'auto'，也可以在不同环境明确注入 CDN 域名。多租户或私有化部署时尤其要小心，硬编码生产 CDN 会让客户环境直接白屏。跨域和安全头怎么配置？Host 加载 Remote 本质上是跨源脚本执行，所以 Remote 域名需要允许正确的 CORS 和静态资源访问。脚本加载通常不需要像接口那样复杂的凭证跨域，但 Source Map、字体、图片和接口请求会受响应头影响。安全上要限制 Remote 来源，不要让配置中心返回任意域名。企业环境还要配合 CSP，把可信 Remote 域名加入 script-src，否则浏览器会直接拦截。Remote 发布失败时怎么降级？Host 应该给每个远程模块包一层错误边界和加载超时处理。入口加载失败时，可以隐藏菜单、展示轻量错误页，或者回退到上一版 Remote 地址。取舍是自动回滚需要更完善的健康检查，否则可能因为一次网络抖动频繁切换版本。至少要把 remoteEntry 加载失败、chunk 404、初始化异常打到监控里，并带上 Remote 名称和版本号。生产部署的核心不是把几个应用放到 CDN 上，而是让 Host 和 Remote 在不同发布节奏下仍然可预测。缓存边界、版本保留、契约兼容、跨域安全和监控回滚都到位，Module Federation 的独立部署才算真正落地。

Module Federation 的测试难点在于：你测到的代码，不一定就是线上组合后的代码。Remote 本地单测通过，Host 集成时可能因为共享依赖版本不一致、remoteEntry 缓存、运行时加载失败而出问题。所以测试策略不能只覆盖组件本身，还要覆盖契约、集成、降级和发布后的真实加载链路。建议把测试分成四层。第一层是 Remote 内部单元测试，确保组件、Hook、工具函数按预期工作；第二层是契约测试，确保暴露模块的 Props、事件和类型没有破坏调用方；第三层是 Host 集成测试，验证真实 remoteEntry 能被加载并完成关键流程；第四层是端到端和发布后探测，确认 CDN、权限、环境变量、缓存策略都没问题。层级越往上越贵，所以不要把所有问题都交给 E2E，单测和契约测试要先挡住大部分低级错误。// contract.test.tsimport type { OrderListProps } from '../src/pages/OrderList'test('OrderList contract keeps required props stable', () => { const props: OrderListProps = { userId: 'u_1', onSelect: () => undefined } expect(props.userId).toBeTruthy()})// playwright: host loads remotetest('host can open order remote', async ({ page }) => { await page.goto('/orders') await expect(page.getByText('订单列表')).toBeVisible() await expect(page.locator('[data-remote="order"]')).toBeVisible()})这两段代码分别挡住不同风险。契约测试不追求验证 UI，而是提醒你“这个暴露模块还是否符合调用方预期”；Playwright 测试则要尽量接近真实环境，加载构建后的 remoteEntry，而不是直接 import 本地源码。很多团队踩坑是 CI 里测的是源码，生产跑的是 CDN 文件，中间缺了一层最关键的组合验证。追问Remote 自己测过了，为什么 Host 还要测？Remote 单测只能证明它在自己的环境里能跑，不能证明它和 Host 的共享依赖、路由上下文、权限上下文能正确配合。Host 测试关注的是组合结果，例如 remoteEntry 是否能加载、Suspense fallback 是否消失、错误边界是否兜住异常。取舍在于 Host 集成测试数量不能太多，否则 CI 会变慢。建议只覆盖登录后首屏、核心业务路径和每个 Remote 的入口页。契约测试应该测什么，不应该测什么？契约测试应该测暴露模块的公开接口，包括 Props、事件、返回类型、必要上下文和约定的 DOM 标识。它不应该测试内部实现，也不应该关心按钮用什么颜色、列表内部怎么分页。边界越清楚，Remote 团队越能自由重构。踩坑是把契约测试写成快照大集合，任何样式变化都让调用方 CI 失败，最后大家只会选择跳过测试。共享依赖版本怎么在测试里发现问题？可以在集成测试启动时打印并断言关键依赖版本，尤其是 React、React DOM、路由和状态库。更实用的做法是在测试环境使用和生产相同的构建产物，让 Module Federation 的 share scope 真正初始化。只在 Jest 里 require('react') 判断单例意义不大，因为它没有复现远程加载过程。版本问题通常表现为 Hook 调用异常、Context 丢失或样式组件主题失效，测试用例要覆盖这些症状。E2E 测试要不要覆盖所有 Remote 页面？不要。Module Federation 项目里 Remote 数量一多，全量 E2E 会慢到没人愿意等，也容易因为无关服务波动导致失败。更好的策略是每个 Remote 保留一条冒烟路径，关键业务再补 2 到 3 条高价值流程。取舍是覆盖率看起来没那么漂亮，但反馈速度和稳定性会更好。细节逻辑仍然交给 Remote 自己的单测和组件测试。发布后还需要做什么测试？需要做合成探测，也就是定时从线上访问 Host，并检查每个 Remote 的入口是否能加载。这个探测要覆盖 remoteEntry 404、跨域错误、初始化失败、白屏和核心文案缺失。很多问题只有 CDN 缓存、Nginx 头、灰度配置参与后才出现，CI 阶段不一定能发现。发布后探测不是替代测试，而是给独立部署加一层保险。Module Federation 的测试重点是把“模块能跑”和“系统能组合起来跑”分开看。单测保证局部质量，契约测试保护边界，集成和线上探测保证真实运行链路，这样才不容易把问题留到用户浏览器里。

大型企业应用使用 Module Federation，最怕把它当成“前端拆仓库工具”。仓库拆开只是结果，真正要设计的是业务域、运行时依赖、权限、发布节奏和故障隔离。一个 ERP、CRM 或运营后台可能有几十个团队参与，如果 Host 既管路由又管业务状态，还顺手持有所有 Remote 的细节，最后只是把单体应用换了一种方式继续维护。更合理的架构是 Host 做薄，平台能力做稳，业务 Remote 做自治。Host 负责应用壳、认证、全局导航、布局容器、权限上下文和 Remote 注册；领域团队负责自己的路由片段、页面、接口适配和局部状态。公共 UI、埋点、国际化、权限 SDK 可以由平台团队维护，但要通过版本化包或共享依赖暴露，不要让每个 Remote 复制一份。企业级架构的关键不是“拆得多细”，而是拆完以后还能统一治理。const remotes = { order: `order@${process.env.ORDER_REMOTE}/remoteEntry.js`, finance: `finance@${process.env.FINANCE_REMOTE}/remoteEntry.js`, crm: `crm@${process.env.CRM_REMOTE}/remoteEntry.js`}new ModuleFederationPlugin({ name: 'enterprise_host', remotes, shared: { react: { singleton: true, requiredVersion: '^18.2.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.2.0' }, '@company/auth': { singleton: true, requiredVersion: '^2.0.0' }, '@company/design-system': { singleton: true, requiredVersion: '^5.0.0' } }})这里建议把 Remote 地址放进环境变量或配置中心，而不是写死在构建产物里。企业环境经常有灰度、专有化部署、私有云和多区域发布，同一套 Host 可能要加载不同版本的 Remote。配置中心还能做开关控制：某个 Remote 健康检查失败时，Host 可以隐藏入口或降级到旧版本。这个能力比多写几个 exposes 更接近企业架构的核心。追问企业级应用按页面拆还是按业务域拆？优先按业务域拆，而不是按菜单或页面数量机械拆分。页面拆分短期看很直观，但订单详情、订单审批、订单售后往往共享同一套领域模型，拆到不同 Remote 后会产生重复接口适配和状态同步问题。按业务域拆能让团队对数据、路由和发布负责，边界更稳定。取舍是业务域 Remote 可能更大，需要做好懒加载和缓存；但它换来的是更清晰的责任边界。Host 应该保存全局状态吗？Host 可以保存认证态、租户、语言、主题、权限这类真正全局的上下文，但不应该保存订单列表筛选条件、财务单据草稿等业务状态。业务状态留在 Remote 内部，Host 只通过路由参数、事件或明确的 SDK 传递必要信息。否则 Host 会逐渐变成隐形单体，任何业务变更都要改主应用。踩坑点是全局 store 看起来方便，半年后会变成所有团队都不敢动的共享泥球。大型企业里的权限和菜单怎么和 Remote 配合？权限最好由统一权限服务计算，Host 根据权限决定入口是否展示，Remote 内部再做细粒度按钮和数据权限校验。不要只靠 Host 隐藏菜单，因为用户仍可能通过地址栏访问 Remote 路由。Remote 初始化时应拿到当前用户、租户和权限摘要，并在请求层继续带上服务端可验证的凭证。边界是前端权限只负责体验和防误操作，真正安全必须由后端接口兜底。如何处理多版本共存和灰度发布？企业应用很少能一次性全量升级，尤其是金融、供应链、内部运营系统。可以让配置中心按用户、租户或区域返回不同 remoteEntry 地址，并在监控里按版本聚合错误。取舍是灰度系统会增加排查复杂度，同一个 Bug 可能只在某个租户的 Remote 版本出现。为了降低成本，Remote 构建产物要带版本号、提交号和构建时间，错误上报也要携带这些信息。设计系统和公共 SDK 升级有什么坑？公共依赖升级是企业级 Module Federation 最常见的事故源。设计系统小版本改了样式变量、权限 SDK 改了初始化时机，都可能影响多个 Remote。建议先在兼容层保留旧 API，再逐步通知业务团队升级，最后才移除旧版本。不要强行让所有团队同一天升级 singleton 依赖，除非你已经准备好回滚和兼容验证。大型企业架构里的 Module Federation，价值在于让组织边界和技术边界尽量一致。Host 保持稳定，Remote 保持自治，平台能力通过契约提供，系统才能在团队数量增加后仍然可维护。

Module Federation 真正解决的不是“把页面拆开”这么简单，而是让多个团队可以按业务节奏独立交付，同时仍然像一个产品一样运行。协作做得好，订单、用户、支付团队各自发布 Remote，Host 只管入口、导航、登录态和公共约束；协作做得差，就会变成一堆互相引用的远程包。比较稳的做法是先定团队边界，再定模块边界。业务 Remote 应该围绕领域能力暴露，例如 order/OrderList、user/ProfilePanel，不要把一个团队内部的按钮、Hook、工具函数随手暴露出去。平台团队负责运行时、共享依赖、发布规范和监控模板，业务团队负责页面、接口适配和降级方案。这个分工慢一点，但能避免后期每次升级 React、路由或 UI 库都要开跨团队大会。new ModuleFederationPlugin({ name: 'order', filename: 'remoteEntry.js', exposes: { './OrderList': './src/pages/OrderList', './OrderRoutes': './src/routes' }, shared: { react: { singleton: true, requiredVersion: '^18.2.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.2.0' }, '@company/ui': { singleton: true, requiredVersion: '^3.4.0' } }})这段配置里的重点不是 exposes 写了什么，而是只暴露稳定能力。OrderList 可以被 Host 或其他业务组合，OrderRoutes 可以被主应用挂载；但订单团队内部的筛选组件如果还在频繁改，就不应该成为远程契约。共享依赖也要写清版本范围，尤其是 React、路由、状态库和设计系统，否则本地没问题，线上可能因为重复实例导致 Hook 报错或样式错乱。追问团队之间应该共享组件还是共享页面？优先共享业务页面或稳定业务能力，不要一开始就共享过细的组件。共享组件复用率更高，但调用方会依赖你的 Props、样式和交互细节，维护成本也会上升。页面级 Remote 的边界更粗，团队能独立测试和发布，适合组织规模变大后的协作。边界是：如果一个能力频繁跟业务规则一起变化，就让负责该业务的团队拥有它；如果它是按钮、表格、弹窗这类通用能力，才进入设计系统。Remote 的接口契约怎么管才不会互相拖累？把 Remote 暴露出来的模块当成公共 API 管理，而不是随手导出的文件。建议为每个暴露模块维护类型声明、变更日志和兼容策略，破坏性变更必须走大版本。TypeScript 可以用 d.ts 包或独立 contract 包同步给调用方，但不要让调用方直接依赖 Remote 的源码路径。踩坑最多的是改了 Props 名称却只测了本团队页面，Host 在运行时才炸。多团队独立发布时如何避免线上互相影响？Remote 发布要有版本化地址、健康检查和回滚入口，Host 不应该永远指向一个不可追踪的最新文件。可以让环境配置中心返回当前可用的 remoteEntry URL，并保留上一版地址作为快速回滚。取舍在于固定版本更稳定但发布链路更重，动态版本更灵活但需要更强监控。生产环境至少要监控 remoteEntry 加载失败和关键页面白屏率。公共依赖到底该不该全部 singleton？不是所有依赖都应该 singleton。React、React DOM、路由实例、状态容器这类有运行时上下文的库，通常需要 singleton；日期库、工具函数、小型纯函数库可以让各 Remote 自带，减少版本协调。过度 singleton 会让平台团队成为依赖升级瓶颈，任何一个 Remote 的版本要求都可能卡住全局。边界是：如果重复加载会破坏上下文或明显增加体积，就共享；如果只是几十 KB 且没有全局状态，独立携带反而省心。协作流程里最容易被忽略的坑是什么？最容易忽略的是“本地联调成功不等于线上协作成功”。本地常常跑的是最新源码，线上加载的是 CDN 上的 remoteEntry，两者版本和缓存策略可能完全不同。另一个坑是只约定技术配置，不约定故障责任：Remote 挂了以后 Host 显示什么、谁收到告警、多久回滚，都要提前写清。Module Federation 能让团队独立，但它不会自动替你建立协作秩序。结论很简单：Module Federation 的多团队协作要先管契约，再谈复用。模块暴露越克制，依赖策略越清楚，发布和回滚越可观测，团队越能真正独立交付。

Module Federation 的问题排查要先分层，不要一看到报错就改 shared。一次 remote 加载失败，可能发生在网络层、remoteEntry 执行层、共享依赖协商层、模块暴露路径层，也可能只是路由或样式副作用。排查顺序应该从“文件能不能拿到”开始，再看“容器能不能初始化”，最后才看业务代码。先确认 remoteEntry 是否真的可用打开浏览器 Network，检查 remoteEntry.js 是否 200、content-type 是否正常、是否被 CDN 缓存到旧版本、是否有 CORS 或 CSP 拦截。很多线上问题不是 Module Federation 本身坏了，而是发布路径、publicPath 或缓存策略错了。// remote devServer 必须允许 shell 跨域访问devServer: { port: 3001, headers: { 'Access-Control-Allow-Origin': '*' }}如果 remoteEntry 返回的是 HTML，通常是路径被网关重写到了首页；如果状态码是 200 但执行报语法错误，要检查构建目标和浏览器兼容。这个阶段不要先动 shared，否则会把简单网络问题排复杂。再看容器初始化和暴露路径Shell 里写的 import('user/App')，必须和 remote 的 exposes 完全对应。大小写、斜杠、别名错一个都会失败。可以在控制台检查 window.user 是否存在，再手动调用 get 方法定位问题。await __webpack_init_sharing__('default')const container = window.userawait container.init(__webpack_share_scopes__.default)const factory = await container.get('./App')const Module = factory()console.log(Module)如果 window.user 不存在，问题在 remoteEntry 加载或 remote name；如果 get('./App') 失败，问题多半在 exposes；如果 factory 执行后业务报错，再进入组件内部调试。shared 依赖怎么排查？共享依赖问题通常表现为 hooks invalid、context 失效、样式库重复注入、运行时版本不匹配。先确认 React 是否只有一份，再看 requiredVersion 和 singleton 配置。不要把所有依赖都 eager，eager 会提高首屏包体，也可能让加载顺序更难控。shared: { react: { singleton: true, requiredVersion: '^18.2.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.2.0' }}取舍在于：共享能减少重复加载，但会增加团队之间的版本耦合。不稳定或频繁升级的业务库，未必适合共享。Source Map 和日志应该怎么配？调试联邦应用时，Source Map 要能区分 Shell 和 remote，否则堆栈里只看到一堆打包后的 chunk 名称。建议 remote 构建时设置独立 namespace，并在错误上报里带上 remoteName、remoteVersion、exposedModule 和 manifestVersion。这样线上看到 Loading chunk failed 时，才能判断是 CDN 缓存、发布缺文件，还是某个用户命中了旧清单。Source Map 不一定要公开暴露给所有用户，生产环境可以上传到监控平台，用错误 ID 反查源码位置。有哪些工具值得放进排查流程？浏览器 DevTools 是第一工具，Network 看入口和 chunk，Console 看容器初始化，Performance 看加载瀑布。React DevTools 适合确认组件树和 Context 是否跨 remote 正常传递，构建分析工具则用来看 shared 是否真的被共享。团队还可以做一个简单的 federation debug 面板，把当前 manifest、remote 版本、加载耗时、失败原因直接展示出来。边界是工具只能缩短定位时间，不能弥补发布规范缺失；如果 remoteEntry 命名不可回滚，再好的面板也只能告诉你它坏了。还有一个容易忽略的点是环境差异。开发、测试、预发、生产最好使用同一套 manifest 结构，只替换域名和版本，不要每个环境写一份完全不同的 remote 配置。否则本地修好的问题，上线后可能因为清单字段或 CDN 路径不同再次出现。追问remoteEntry 明明 200，为什么还是加载失败？先看返回内容是不是 JavaScript，而不是网关兜底返回的 index.html。再看 remoteEntry 里引用的 chunk 是否能继续加载，很多问题发生在二级 chunk 的 publicPath 上。还要检查 CSP、跨域头和 CDN 缓存，尤其是 Shell 更新了 manifest，但用户还拿着旧 remoteEntry。边界是 200 只能说明入口文件到了，不代表容器初始化成功。怎么判断是 shared 冲突还是业务代码报错？如果报错出现在 container.init 或共享作用域协商阶段，优先查 shared。若 container.get('./App') 能拿到 factory，执行组件时才报业务异常，就应该回到 React DevTools、Source Map 和业务日志。shared 冲突常见特征是 React hooks、context、styled-components 或路由上下文异常。踩坑是把业务异常误判为依赖冲突，结果越改 shared 越乱。本地调试多个 remote 有什么坑？端口、跨域、热更新和版本不一致是最常见的四类坑。Shell 本地连 remote 本地时，要确认 remote dev server 已启动且 remoteEntry 地址没有写死到测试环境。HMR 在联邦场景下不一定每次都可靠，遇到奇怪状态先刷新页面和清缓存。取舍是本地全链路调试更接近真实环境，但启动成本和不稳定因素也更多。线上应该监控哪些指标？至少监控 remoteEntry 加载耗时、chunk 加载失败率、container 初始化错误、模块 get 失败和降级 UI 命中次数。只看业务接口错误不够，因为联邦问题可能在页面渲染前就失败了。建议日志里带上 shell 版本、remote 名称、remote 版本和用户命中的 manifest。边界是监控不能替代降级，告警告诉你出事了，fallback 才能让用户不白屏。

把现有应用迁移到 Module Federation，最忌讳一上来就按团队边界大拆。更稳的路线是先让老应用作为 Shell 保持不动，再把低风险页面、公共组件或独立业务域拆成 remote，等发布、监控、回滚都跑顺后再扩大范围。迁移的本质不是换插件，而是改变构建、发布和依赖协作方式。迁移前先看哪些条件？先评估三件事：应用是否有清晰的业务边界，依赖版本是否可统一，发布链路是否支持多产物部署。如果当前项目连 React、路由、状态库版本都混乱，直接上联邦只会把问题放大。还要看团队协作方式：Module Federation 适合多个团队独立交付，不适合一个小团队为了“微前端”而强拆。// shell webpack.config.jsnew ModuleFederationPlugin({ name: 'shell', remotes: { user: 'user@https://cdn.example.com/user/remoteEntry.js' }, shared: { react: { singleton: true, requiredVersion: '^18.2.0' }, 'react-dom': { singleton: true, requiredVersion: '^18.2.0' } }})这段配置看起来简单，真正的边界在 shared。版本写得太宽，可能引入未知兼容问题；写得太死，又会让 remote 发布受 Shell 牵制。一般建议框架类依赖单例且收紧版本，工具类依赖按体积和兼容性决定是否共享。迁移策略怎么选？第一种是“壳保留，页面外拆”：老应用继续负责登录、菜单、路由和全局布局，新业务页面逐步变成 remote。这种风险最低，适合后台系统和中大型 ToB 应用。第二种是“组件先行”：先拆设计系统、图表、富文本、上传器这类公共组件。好处是收益快，但要注意样式隔离和 peer dependency，否则公共组件一升级，多个业务同时出问题。第三种是“按业务域拆分”：订单、用户、营销各自独立构建和发布。它最符合微前端理想状态，但要求团队边界、接口契约、监控和回滚都比较成熟。路由和发布怎么兜底？迁移期必须把 remote 加载失败当成常态处理。Shell 不应该因为一个 remoteEntry 404 就白屏，而要展示降级页、错误边界或回退到旧页面。发布时建议 remote 使用不可变版本路径，Shell 读取一份可回滚的 manifest。const RemoteUser = React.lazy(() => import('user/App').catch(() => import('./fallback/UserFallback')))这类兜底不是锦上添花，而是迁移能不能上线的前提。尤其灰度阶段，新旧页面可能同时存在，日志里必须能区分用户命中了哪个 remote 版本。数据、样式和权限要不要一起拆？不要急着一起拆。页面可以先联邦化，但登录态、权限、主题和埋点最好仍由 Shell 统一提供，remote 通过明确的 props、事件或 SDK 获取上下文。否则每个 remote 都复制一套鉴权和埋点，迁移后看似独立，实际排查问题更慢。样式也要提前约定：CSS Modules、Shadow DOM、前缀命名或设计系统变量至少选一种，否则新旧页面并存时很容易互相污染。追问应该先拆公共组件还是业务页面？如果团队第一次做 Module Federation，优先拆低风险业务页面，而不是核心公共组件。业务页面失败时可以路由回退，公共组件失败会影响多个页面，事故半径更大。公共组件适合在共享依赖、样式隔离和版本发布流程稳定后再拆。取舍点是页面拆分收益慢一点，但更容易把迁移风险控制在单个业务域内。迁移时 shared 依赖怎么定？React、ReactDOM、路由和状态管理这类运行时强相关依赖，通常要设 singleton。lodash、dayjs 这类工具库是否共享，要看体积、版本差异和缓存收益，不要为了“少打包一点”制造版本耦合。踩坑最多的是 remote 自己带了一份 React，Shell 也有一份，最后 hooks 报错却很难定位。边界是共享依赖只能解决前端运行时复用，不能替代包管理和版本治理。如何判断迁移已经可以扩大范围？看四个信号：remote 加载失败有降级，发布后能快速回滚，监控能看到加载耗时和错误率，团队知道谁负责哪个 remote。只要其中一个缺失，就不要急着拆核心链路。迁移不是拆得越快越好，而是每拆一块都能独立发布、独立定位、独立恢复。很多项目失败不是技术不通，而是拆完之后没有人对线上 remote 负责。老项目不是 Webpack 还能迁移吗？可以，但要先确认当前构建工具的联邦插件成熟度。Vite、Rspack、Rsbuild 都有方案，但不同插件对 CSS、动态 remote、SSR 和 shared 的支持细节不一样。稳妥做法是先做一个真实业务切片验证，而不是只跑 demo。边界是如果项目强依赖老旧 loader、全局变量和隐式副作用，迁移前要先整理工程结构。

Module Federation 的未来不会只停在 Webpack 插件上，它更像一种前端运行时组合协议：不同团队、不同构建工具、不同发布节奏的应用，可以在浏览器里按需拼装。趋势大致有三条：构建工具解耦、运行时治理增强、跨端与边缘场景扩展。为什么会从 Webpack 走向多构建工具？早期 Module Federation 和 Webpack 绑定很深，remoteEntry、share scope、runtime container 都来自 Webpack 的实现。现在 Vite、Rspack、Rsbuild、Rollup 生态都在补齐联邦能力，核心原因不是“换个打包器更时髦”，而是大型应用需要更快的本地启动、更低的构建成本，以及更容易接入已有工程。// rspack.config.jsconst { ModuleFederationPlugin } = require('@module-federation/enhanced/rspack')module.exports = { plugins: [ new ModuleFederationPlugin({ name: 'shell', remotes: { order: 'order@https://cdn.example.com/order/remoteEntry.js' }, shared: { react: { singleton: true }, 'react-dom': { singleton: true } } }) ]}但这里有边界：多构建工具支持不等于随便混用。团队要先确认 remote 格式、ESM/CJS 输出、CSS 注入、公共依赖版本协商是否一致，否则本地能跑，线上可能在首屏、样式隔离或 chunk 加载上翻车。运行时治理会变得更重要吗？会。未来的重点会从“能不能加载远程模块”转向“能不能稳定、安全、可观测地加载”。大型团队会需要远程模块清单、灰度发布、版本锁定、回滚、SRI 校验、加载耗时监控和依赖冲突报警。尤其是把 remoteEntry 放到 CDN 后，缓存策略、文件不可变命名和清单更新就会影响事故半径。{ "remotes": { "order": { "entry": "https://cdn.example.com/order/1.8.3/remoteEntry.js", "version": "1.8.3", "integrity": "sha384-..." } }}这个方向的取舍很现实：治理越细，平台成本越高；治理太弱，微前端会变成“分布式脚本引用”。比较稳的做法是先管住入口清单和共享依赖，再逐步接入灰度、告警和回滚。边缘计算和 SSR 会怎样影响 Module Federation？SSR、Streaming、Edge Runtime 会让 Module Federation 从浏览器运行时扩展到服务端组合。比如 Shell 在服务端决定加载哪个 remote，先输出骨架，再把局部功能流式返回。好处是首屏更可控，也能按地区、租户、实验策略选择不同模块。踩坑也明显：服务端不能假设所有 remote 都有 window、document；共享依赖要区分 server/client 版本；remote 不可用时必须有降级 UI。否则一次 remote 超时，就可能拖垮整个页面响应。AI 和自动化会真正改变什么？更实际的变化会发生在发布前后。平台可以根据路由访问量、错误率和用户路径，自动给高概率命中的 remote 做 preload，也可以在某个版本错误率升高时把 manifest 切回上一版。这里不要迷信“AI 自动调度”，因为预测错了会浪费带宽，甚至把低端设备的主线程压满。比较可落地的做法是先用规则驱动：高频路由预加载、低频模块懒加载、异常版本自动降级，再把历史数据用于优化阈值。另外，组织层面的演进也不能忽略。Module Federation 越普及，越需要平台团队定义 remote 命名、版本保留周期、灰度比例和事故响应规则。否则技术上已经拆开，协作上仍然靠口头约定，最后会把跨团队发布变成新的瓶颈。追问Module Federation 会被 Vite 或 Rspack 取代吗？不会，二者不是同一层东西。Vite、Rspack 是构建工具，Module Federation 解决的是运行时模块组合和依赖共享。未来更可能出现的是“Webpack 联邦实现”逐渐让位给“跨构建工具联邦协议”。真正要取舍的是团队愿不愿意为更快构建迁移工具链，同时承担插件成熟度和生态差异的风险。远程模块市场靠谱吗？内部模块市场有价值，公开市场要谨慎。企业内部可以把设计系统、结算组件、权限组件做成可搜索、可审计、可版本化的 remote，提高复用效率。边界在于业务组件通常依赖上下文、埋点、权限和主题，脱离原系统后复用成本并不低。踩坑最多的是只发布组件，不发布版本说明、依赖约束和降级策略。共享依赖未来会怎么演进？共享依赖会从简单的 singleton 配置，走向更明确的版本策略和运行时诊断。React 这类框架依赖通常必须单例，否则 hooks、context、路由状态都可能异常。工具层可以自动提示重复实例、版本漂移和 eager 配置不当，但不能替团队决定兼容边界。实际项目里要把共享依赖当成架构契约，而不是随手复制的配置。安全治理需要做到什么程度？至少要做到 remoteEntry 来源可信、版本可追踪、发布可回滚。对外部或跨团队 remote，建议加白名单、SRI、CSP 和发布审批，不要让任意 URL 进入运行时加载链路。取舍是安全校验会增加发布流程和调试成本，但它能避免供应链脚本被替换后全站中招。边界是前端校验不能替代后端权限，remote 里所有敏感接口仍必须走服务端鉴权。

直接回答存储型 XSS 和反射型 XSS 的核心区别在于恶意脚本是否被服务器保存。存储型 XSS 会把 payload 写进数据库、评论、资料、工单、消息等持久化位置，之后每个访问相关页面的用户都可能中招；反射型 XSS 通常藏在 URL 或表单参数里，服务器把它原样拼回响应，只有点击恶意链接或提交特定请求的用户会触发。一个像埋地雷，一个像递刀片，前者影响面更大，后者更依赖诱导。防护思路也不同。存储型要重点管住“写入后再展示”的完整链路，包括后台审核页、管理端列表和导出内容；反射型要重点检查搜索、错误提示、跳转、登录回跳这类即时响应。两者共同底线是按输出上下文编码，不把用户输入当 HTML、JS、CSS 或 URL 直接拼接。输入过滤可以减少脏数据，但不要把它当唯一防线，因为同一份数据在不同上下文里危险点完全不同。还有一个容易忽略的边界：同一个字段今天只在纯文本位置展示，明天可能被产品放进富文本卡片或运营邮件里，所以“当前没事”不能当成长期安全结论。对比代码// 反射型：q 来自本次请求，立刻进入响应app.get('/search', (req, res) => { res.send(`<p>搜索：${escapeHtml(req.query.q || '')}</p>`);});// 存储型：评论先入库，展示时仍要编码app.get('/comments', async (req, res) => { const rows = await db.query('select content from comments'); res.send(rows.map(r => `<p>${escapeHtml(r.content)}</p>`).join(''));});这段示例故意把编码放在输出侧。很多团队喜欢在入库前“清洗干净”，但评论可能在网页、App WebView、邮件模板、后台表格里被复用，不同场景需要不同编码。入库前可以做长度、类型和业务规则校验；真正决定是否会执行脚本的，往往是展示时的上下文。追问为什么存储型 XSS 通常更危险？因为它不需要每次诱导用户点击恶意链接，只要恶意内容留在系统里，后续访问者都会暴露在风险下。评论区、用户昵称、客服消息、站内信、后台备注都可能成为传播点。更麻烦的是管理员也可能访问这些内容，一旦后台中招，攻击者可能拿到更高权限。边界是反射型如果结合钓鱼、短链接和已登录状态，也能造成严重后果，不能简单认为它只是中危。反射型 XSS 为什么还常见？因为很多页面会把用户输入立即展示出来，比如搜索词、错误信息、表单校验结果和跳转提示。开发者容易觉得“只是显示一下参数”，于是直接拼 HTML。反射型的踩坑点在于它经常出现在边角页面，不在主流程测试范围内。尤其是老服务端模板，一段字符串拼接就可能把 URL 参数变成可执行脚本。输入过滤和输出编码应该怎么取舍？输入过滤适合做业务合法性校验，例如昵称长度、评论最大字数、URL 是否属于允许域名。输出编码负责安全上下文，例如 HTML 文本、HTML 属性、JavaScript 字符串、CSS 和 URL 编码规则都不一样。只做输入过滤会遇到绕过，也会误伤正常内容；只做输出编码又可能让垃圾数据长期污染数据库。实际项目里两者都要有，但安全兜底应放在输出编码和安全渲染上。富文本场景怎么处理存储型 XSS？富文本不能简单转成纯文本，否则业务体验会崩；但也不能相信编辑器输出，因为攻击者可以绕过前端直接调接口。更合理的是服务端或展示层使用白名单清洗，只允许必要标签和属性，例如段落、列表、链接、加粗和代码。链接要额外限制协议，图片要限制来源和大小。踩坑点是后台预览、移动端 WebView、邮件通知也要走同一套清洗规则，否则主站安全，旁路页面仍然中招。组合防护应该包含哪些层？第一层是输出编码和安全模板，保证默认渲染不执行脚本。第二层是富文本清洗、URL 协议白名单和危险 API 禁用，减少特殊场景的攻击面。第三层是 CSP、Cookie HttpOnly/SameSite/Secure、权限最小化和审计日志，降低漏洞被利用后的收益。最后要把安全测试放进流程，评论、搜索、资料、后台列表这些输入展示链路，每次改版都应该有回归用例。

直接回答DOM 型 XSS 是漏洞发生在浏览器端的一类 XSS：页面脚本从 location、postMessage、localStorage、URL 参数等来源读取不可信数据，再写入 innerHTML、document.write、eval、setTimeout(string) 等危险位置，最终让浏览器执行了攻击者控制的代码。它和反射型、存储型最大的区别是，恶意内容不一定经过服务器响应，服务端日志里可能什么都看不到。检测 DOM 型 XSS 要抓两件事：source 和 sink。source 是不可信输入从哪里来，sink 是它被送到哪里执行或解析。修复时优先改 sink，例如能用 textContent 就别用 innerHTML；确实要渲染 HTML，就先清洗；涉及 URL 跳转、iframe、图片地址时，要做协议和域名白名单。DOM XSS 难发现，不是因为原理复杂，而是因为前端状态太多，数据在路由、组件、缓存和第三方库之间绕几圈后，没人记得它最初来自用户。危险与修复示例const keyword = new URLSearchParams(location.search).get('q') || '';// 危险：把 URL 参数当 HTMLresult.innerHTML = `搜索：${keyword}`;// 安全：只按文本显示result.textContent = `搜索：${keyword}`;如果业务必须展示高亮 HTML，不要手写几个 replace 就收工。HTML 上下文、属性上下文、URL 上下文的编码规则不同，手写函数很容易漏掉实体编码、大小写、闭合标签和 SVG 事件。用成熟库清洗，再配合单元测试覆盖常见 payload，会比临时补丁可靠得多。追问DOM 型 XSS 和反射型 XSS 怎么区分？反射型 XSS 通常是服务器把请求参数拼进响应，漏洞点在服务端输出。DOM 型 XSS 则是浏览器端脚本自己读取并写入 DOM，服务器可能只是返回同一个静态页面。两者有时会混在一起，例如 URL 参数先被服务端渲染，再被前端脚本二次处理。判断边界时可以看恶意 payload 是否出现在 HTTP 响应体里，如果响应体没有但页面执行了，往往就是 DOM 型。常见 source 和 sink 有哪些？常见 source 包括 location.href、location.search、location.hash、document.referrer、window.name、postMessage、localStorage 和接口返回中的用户字段。常见 sink 包括 innerHTML、outerHTML、insertAdjacentHTML、document.write、eval、new Function、字符串形式的 setTimeout。取舍点是有些 API 本身不是绝对禁用，比如 innerHTML 渲染可信模板可以接受。问题在于不可信数据流进这些位置时，必须有清洗、编码或白名单校验。手动测试 DOM XSS 应该怎么做？先找页面里会读取 URL、hash、消息事件和本地存储的代码，再看这些值是否进入危险 sink。测试 payload 不要只用 <script>alert(1)</script>，现代浏览器和插入方式下它经常不执行，可以补充 <img src=x onerror=alert(1)>、SVG、属性闭合等变体。测试时要覆盖路由切换、弹窗打开、搜索建议、富文本预览等交互路径。踩坑点是单页应用很多逻辑懒加载，页面刚打开没触发，不代表没有漏洞。自动化工具能发现所有 DOM XSS 吗？不能，但它们能显著降低漏检。静态扫描能找出 source 到 sink 的可疑数据流，动态扫描能在真实浏览器里观察 payload 是否执行。边界在于复杂框架、混淆代码、运行时拼接和第三方组件会让工具误报或漏报。比较稳的做法是把 Semgrep/ESLint 规则放进 CI，再对高风险页面做人工复核和浏览器动态测试。防护 DOM XSS 的组合策略是什么？第一层是安全 API：文本用 textContent，属性用框架绑定，不把字符串当代码执行。第二层是输入和 URL 白名单，特别是跳转、iframe、图片和下载链接。第三层是富文本清洗和 CSP，减少漏网内容执行脚本或外传数据。最后还要保护 Cookie，给会话 Cookie 加 HttpOnly、Secure、SameSite，这样即使某处出现脚本执行，攻击收益也会被压低。

直接回答Content Security Policy，简称 CSP，是浏览器执行的一套资源加载和脚本执行规则。它不能替代输出编码，也不能把脏 HTML 自动洗干净，但它能在 XSS payload 混进页面后继续拦一刀：不允许内联脚本执行，不允许加载未知域名脚本，不允许 eval，也能限制表单提交、iframe 嵌套和基础 URL。对安全来说，CSP 更像安全带，不是刹车；撞车前最好别撞，真撞上时它能降低伤害。一个可落地的 CSP 通常从 Report-Only 开始，先收集违规报告，再逐步收紧。新项目优先使用 nonce 或 hash，少用 'unsafe-inline'；老项目如果内联脚本很多，可以先把脚本拆出去，再引入 nonce。CSP 的难点不是写出一条很漂亮的 header，而是在业务脚本、监控、A/B 测试、支付、客服和广告之间找到可维护的边界。推荐配置Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; img-src 'self' https: data:; connect-src 'self' https://api.example.com; report-uri https://report.example.com/csp;nonce 必须每个响应重新生成，并且只发给服务器确认过的脚本标签。不要把 nonce 写死在模板、缓存片段或全局变量里，否则攻击者只要读到一次就能复用。object-src 'none'、base-uri 'self'、frame-ancestors 这些指令常被忽略，但它们能挡住不少老式插件、base 标签劫持和点击劫持组合拳。追问CSP 能不能彻底解决 XSS？不能，CSP 是缓解措施，不是根治手段。真正的根治仍然是按上下文输出编码、富文本白名单清洗、避免危险 DOM API。CSP 的价值在于漏洞发生后减少脚本执行和数据外传，例如阻止未知域名脚本、限制 connect-src。边界是浏览器兼容、策略误配、已有可信脚本被利用时，CSP 仍可能被绕过。nonce、hash 和白名单域名该怎么选？nonce 适合服务端渲染页面，因为每次响应都能给合法脚本发一个随机通行证。hash 适合内容固定的内联脚本，脚本一改 hash 就要更新，维护成本更高但不依赖运行时注入。域名白名单看起来简单，却容易因为信任整个 CDN 或第三方域名而扩大攻击面。取舍上，新系统优先 nonce/hash，域名白名单只给确实需要的外部资源，别把 https: 当万能许可。为什么很多 CSP 最后都加了 'unsafe-inline'？通常是历史包袱：页面里有大量内联事件、内联脚本、老组件或第三方片段，一关就坏。加 'unsafe-inline' 能快速恢复业务，但也会让 CSP 对内联 XSS 的防护大打折扣。更好的迁移方式是先用 Content-Security-Policy-Report-Only 收集问题，再按页面分批移除内联脚本。踩坑点是报告量会很大，需要聚合去重，不然安全团队很快被噪音淹没。strict-dynamic 有什么用？strict-dynamic 表示只要一个带 nonce 或 hash 的可信脚本被允许执行，它动态加载的后续脚本也可以被信任。它适合现代前端打包和运行时加载场景，能减少维护一长串脚本域名的痛苦。边界在于你必须先保护好入口脚本，入口脚本如果被污染，动态信任会放大问题。老浏览器支持也要评估，必要时保留兼容性的域名策略。CSP 上线最容易踩哪些坑？第一是把策略一次性收太紧，导致支付、验证码、地图、监控全挂。第二是只配置 script-src，却忘了 connect-src、frame-src、form-action，攻击者仍可能把数据送出去。第三是没有监控报告，线上误杀只能靠用户投诉。实战里建议按页面或业务域灰度，先 Report-Only，再 Enforcement，并把违规报告接入告警和例外审批。