# 1. qiankun 在基于 single-spa 的微前端框架的工程边界与现代应用 A qiankun 在 single-spa 生命周期模型上补充 HTML Entry、沙箱与样式隔离，主打存量系统低改造成本接入 ✓ 正确答案 B qiankun 不依赖 single-spa，是独立框架 C qiankun 的 HTML Entry 是构建期静态解析的 D qiankun 只能用于同技术栈应用
# 2. micro-app（京东）在 Web Components 基础的微前端工程实践 A micro-app 以自定义元素作为子应用容器，支持元素级 scoped 与 shadow 双模式样式隔离，声明式接入 ✓ 正确答案 B micro-app 要求子应用必须改造为生命周期函数导出 C micro-app 的样式隔离只有 shadow 一种模式 D micro-app 不支持同一子应用多实例挂载
# 3. wujie（无界）在基于 Web Components 的微前端工程应用 A 无界用 iframe 承载 JS 执行、WebComponent 承载 DOM 呈现，规避纯 iframe 的弹窗问题且无代理逃逸面 ✓ 正确答案 B 无界的子应用 UI 直接显示在 iframe 内 C 无界完全消除了 DOM 同步成本 D 无界与 qiankun 的隔离机制完全相同
# 4. garfish（字节跳动）在国产化微前端框架的工程边界 A garfish 不支持按需加载子应用 B garfish 绑定特定前端框架，不支持其他技术栈 C garfish 与 qiankun 的实现细节完全相同 D garfish 以路由驱动 + 模块加载 + 沙箱的模型提供应用治理，特点在插件化与性能导向 ✓ 正确答案
# 5. qiankun 的 import-html-entry 与应用加载流水线 A 严格 CSP 与运行时内联脚本注入天然兼容 B import-html-entry 在构建期静态生成子应用产物 C HTML 中脚本的执行顺序可以任意调整 D import-html-entry 运行时 fetch 并解析远程 HTML，改写成子应用基址后按序注入执行，与构建期联邦模型互补 ✓ 正确答案
# 6. Module Federation 的运行时共享模块与版本协商 A 共享依赖经 share scope 注册，按 requiredVersion 与 singleton 策略协商复用或自载，协商失败会出现双实例故障 ✓ 正确答案 B 共享依赖只要声明了 shared 就必然单例复用 C requiredVersion 写精确版本是最佳实践 D 版本协商是构建期完成的，运行时无决策
# 7. 微前端的拆分策略（按业务域、页面、功能） A 按业务域拆分不需要治理共享逻辑 B 拆分粒度越细一定越好 C 按业务域拆分团队边界最清晰，按页面拆分激活直观，按功能拆分拼装灵活但编排复杂，粒度服从团队边界 ✓ 正确答案 D 页面级拆分适合跨页面强关联场景
# 8. EMP（基于 Module Federation）的工程化扩展 A EMP 在 MF 之上提供共享目录、版本治理与联邦可视化，把联邦机制变成平台级能力 ✓ 正确答案 B EMP 是替代 Module Federation 的独立实现 C EMP 只提供 devtools，无治理能力 D EMP 适合所有规模的组织，无边界
# 9. icestark 与 Garfish 在阿里生态微前端的工程价值 A Garfish 不支持插件化扩展 B icestark 内置完整 JS 沙箱能力 C 两者都依赖特定 UI 框架才能工作 D icestark 走轻量应用管理与路由分发、契合 ice 生态，Garfish 提供完整沙箱与插件化治理，按生态与治理深度选型 ✓ 正确答案
# 10. Module Federation 的 shared 配置，singleton、strictVersion 与 requiredVersion 的版本冲突检测与运行时行为 A requiredVersion 写越精确越能避免协商冲突 B singleton 允许共享依赖多副本共存 C strictVersion 只在非单例场景生效 D requiredVersion 决定版本匹配，singleton 强制单例并降级告警，strictVersion 把版本不匹配升级为加载报错 ✓ 正确答案
# 11. 微前端主子应用路由（基于 single-spa/qiankun/wujie） A 三种框架都以基座路由接管 + 子应用前缀激活协同，差异在子应用路由的自主性（自管/同步/iframe 桥接） ✓ 正确答案 B 子应用路由可以任意使用根路径而不冲突 C history 模式无需前缀约定 D wujie 的子应用没有独立路由能力
# 12. Webpack Module Federation 2.5+ 的新特性 A 2.5+ 的运行时与 1.x 完全兼容，可直接迁移 B 2.5+ 只增加性能优化，无类型与调试能力 C MF 2.5+ 放弃了与 webpack 的兼容 D MF 2.5+ 增强远程模块类型、联邦调试面板与 Vite/Rspack 适配，解决契约与可观测性短板 ✓ 正确答案
# 13. 微前端架构模式涉及的核心数据结构与算法（路由分发、模块加载、状态同步） A 路由匹配只需要前缀比较，无需注册表 B 微前端运行时内核是应用注册表、模块缓存表与状态订阅表，配以规则匹配、加载编排与版本分发算法 ✓ 正确答案 C 模块加载无需缓存与并发控制 D 状态同步全量广播无需版本号与剪裁
# 14. Bit 在组件级别（而非应用级别）的微前端工程价值 A Bit 与应用级微前端解决的是同一个问题 B Bit 以组件为独立版本与发布单元实现跨项目共享，与应用级微前端互补而非替代 ✓ 正确答案 C 组件级共享不需要契约与治理 D Bit 只支持单一框架
# 15. 微前端的路由分发（主应用路由 vs 子应用路由）的工程实践 A 子应用前缀下的未知路径应由主应用路由接管 B 子应用可以自由修改全局路由表 C 主应用管全局结构与激活，子应用管前缀内视图，跨应用跳转经主应用、子应用域内 404 由子应用兜底 ✓ 正确答案 D 路由分发无需处理直接访问 URL 的刷新场景
# 16. 微前端的公共依赖管理（共享 npm 包 vs Module Federation shared） A npm 共享天然保证运行时单例 B 所有公共依赖都应走 MF shared 以节省体积 C 框架类依赖需 MF shared + singleton 保证单例，业务共享宜 npm 版本化 + 契约治理，按运行语义选型 ✓ 正确答案 D 业务组件适合运行时共享实现隐式升级
# 17. 微前端的生命周期挂载（bootstrap、mount、unmount） A 生命周期执行可以不同步，基座无需等待 B bootstrap 在每次激活时都重新执行 C mount 无需幂等，重复调用无害 D bootstrap 初始化一次、mount/unmount 可多次且必须幂等并异步完成，基座按契约串行编排 ✓ 正确答案
# 18. 微前端的应用间通信（CustomEvent、props、状态管理） A 事件通道不需要命名空间治理 B 所有通信都应该走全局状态以保持统一 C 受控交互用 props、全局通知用事件、共享数据用状态层，通信需契约化与生命周期管理 ✓ 正确答案 D 通信订阅无需在卸载时清理
# 19. 微前端的预加载策略（preload、prefetch）的工程性能优化 A 预取无需考虑与首屏资源的带宽竞争 B 预取所有子应用全部资源是最优策略 C 框架级预加载与浏览器级预取会互相替代，只需其一 D 当前应用资源用 preload、下一跳应用入口空闲 prefetch，控制预取体积与并发并用命中率评估策略 ✓ 正确答案
# 20. 微前端在 SSR（子应用独立 SSR）的工程边界与现代实践 A SSR 场景无需关心共享依赖的单例性 B 子应用 SSR 失败会导致整页不可用 C 子应用独立 SSR 需保证水合一致与部分降级，现代实践以边缘 SSR、流式片段输出与联邦协同解决组合时序 ✓ 正确答案 D 流式渲染会拖慢整页 TTFB
# 21. 微前端的全局错误处理与降级（子应用崩溃）的工程策略 A 崩溃降级无需上报与监控 B 子应用崩溃时应整页刷新恢复 C 错误处理按子应用边界、基座全局与兜底页分层，崩溃降级到区域占位并支持重试恢复与防风暴 ✓ 正确答案 D 子应用崩溃率不是核心指标，无需纳入 SLO
# 22. 微前端的版本管理与发布协调（统一发布 vs 独立发布）的工程价值 A 发布模型选择与变更耦合度无关 B 统一发布适合大规模高并发团队 C 独立发布不需要契约测试与组合冒烟 D 独立发布带来节奏自主与风险局部化但需版本矩阵与组合验证，统一发布确定性强但被最慢团队拖累 ✓ 正确答案
# 23. 微前端的 CSS 隔离方案对比，qiankun scoped css、Shadow DOM、CSS-in-JS 与 BEM 命名约定的工程取舍 A CSS-in-JS 可以隔离第三方库的全局样式 B BEM 命名可以彻底消除样式冲突 C Shadow DOM 与 scoped css 的隔离机制相同 D BEM 靠约定、CSS-in-JS 靠构建期作用域、scoped css 靠运行时改写、Shadow DOM 靠浏览器封装，按场景组合使用 ✓ 正确答案
# 24. micro-app 与 Module Federation 在主子应用通信、依赖共享与版本冲突的工程取舍 A micro-app 侧重应用编排与事件通信，MF 侧重运行时依赖共享与版本协商，工程上常组合使用 ✓ 正确答案 B MF 提供应用间通信的标准协议 C micro-app 的共享依赖在运行时自动协商版本 D 两种方案解决完全相同的问题，可互换
# 25. qiankun 的 loadMicroApp 与 registerMicroApps 在微前端按需加载与全量注册的现代工程价值 A registerMicroApps 支持同页多实例 B loadMicroApp 会自动按路由激活子应用 C registerMicroApps 提供路由托管的声明式注册，loadMicroApp 支持无路由的动态按需加载与多实例嵌入 ✓ 正确答案 D 两种 API 能力完全相同，只是写法不同
# 26. 微前端的基座-子应用模式与完全独立模式在团队协作与发布节奏的边界 A 完全独立模式适合需要统一鉴权与导航的场景 B 基座模式统一入口与治理但基座成为公共变更点，完全独立模式无公共依赖但体验一致靠约定，按规模与公共性选择 ✓ 正确答案 C 基座模式中子应用可以自由修改基座 D 两种模式完全互斥，只能固定选一种
# 27. Micro-App 的 html entry 加载模式与 qiankun 的 entry js 模式在首屏速度与现代构建的取舍 A HTML Entry 灵活兼容存量但多一轮解析且资源链式发现，entry JS 与现代构建匹配、加载并行，按存量与性能取舍 ✓ 正确答案 B HTML Entry 的首屏性能一定优于 entry JS C entry JS 模式可以加载任意非构建产物 D 两种模式在现代构建下没有差异
# 28. Module Federation 的 exposes/remotes/shared 三个核心配置在大型分布式应用的工程实践 A remotes 地址可以硬编码进构建配置 B exposes 应该暴露应用的全部内部模块 C exposes 定义提供契约、remotes 定义消费引用、shared 定义共享基线，大型工程以目录化与平台模板治理并前置校验 ✓ 正确答案 D shared 策略由各团队自行决定即可
# 29. 微前端在 Vite/Rspack 模块联邦（Vite 5+ 支持） A Vite 不支持联邦，只能使用 webpack B Vite dev 模式与 build 模式的联邦行为完全一致 C 不同构建器的远程模块无法互操作 D Vite 5+ 经增强插件、Rspack 原生支持联邦，dev 与 build 行为不同，跨构建器依赖统一运行时与契约测试 ✓ 正确答案
# 30. 子应用独立部署 vs 联合发版在大规模团队（数百人）的协作工程边界 A 大规模团队按变更影响面分流：局域变更独立部署、跨域变更联合窗口，并配套契约测试与组合级灰度回滚 ✓ 正确答案 B 数百人团队必须全部联合发版保证一致 C 独立部署不需要契约测试，靠人工协调 D 跨域变更也可以随意独立发布
# 31. 微前端中主子应用的鉴权（JWT、Cookie）传递与 Session 同步策略 A JWT 由基座统一获取经受控通道下发，Cookie 同域自动携带，登录、刷新与登出经统一广播同步 ✓ 正确答案 B 每个子应用应各自实现完整登录流程 C 登出后子应用可继续持有会话凭据 D token 过期时各子应用各自跳转登录页即可
# 32. qiankun 的 import-html-entry 加载远程 HTML 在 CSP 严格部署的边界与现代 webpack/vite 联邦的差异 A HTML Entry 与 JS Entry 的 CSP 行为完全相同 B 严格 CSP 下 qiankun 无需任何调整即可工作 C 联邦的 remoteEntry 也依赖 eval 执行 D import-html-entry 的运行时注入与内联执行和严格 CSP 冲突，联邦的构建产物标准加载天然 CSP 友好 ✓ 正确答案
# 33. 微前端 entry 文件与子应用激活策略在 single-spa / qiankun / micro-app / wujie 之间的工程取舍 A 四种框架的 entry 与激活策略完全相同 B single-spa/qiankun 以生命周期契约 + 路由激活为主，micro-app/wujie 以元素声明 + HTML 加载为主，按接入门槛与控制力取舍 ✓ 正确答案 C micro-app 要求子应用必须暴露生命周期函数 D wujie 不支持路由联动
# 34. 微前端基座（main app）路由变化触发子应用 bootstrap / mount / unmount 的执行模型差异 A wujie 的子应用完全由基座控制渲染时机 B 所有框架都在主线程串行调度全部生命周期 C single-spa 用导航队列串行调度生命周期，qiankun 在其上叠加缓存与手动加载，wujie 以 iframe 自治 + 容器显隐为主 ✓ 正确答案 D 路由变化不会触发生命周期调用
# 35. 基座与子应用独立部署时如何约定接口契约并防止版本漂移 A 契约只需写在文档里，靠开发自觉遵守 B 独立部署下接口契约需版本化并以双向契约测试与兼容矩阵防漂移，breaking 变更走联合窗口 ✓ 正确答案 C 子应用回滚不需要校验与基座的契约兼容 D 契约漂移只能在上线后由用户发现
# 36. 子应用按需加载策略（路由级 / 组件级）在资源预算与首屏体验之间的工程平衡 A 组件级按需加载会增加首屏资源量 B 路由级按需保证不激活不加载，组件级按需精细控制首屏，预加载在空闲期提前获取以平衡切换体验 ✓ 正确答案 C 预加载可以无限制使用以提升体验 D 按需加载策略不需要预算门禁
# 37. 基座与子应用独立 CI / 独立灰度发布的工程范式与回滚策略 A 基座与子应用独立流水线与门禁，灰度按应用/组合/用户分桶，回滚以配置切换与组合快照执行 ✓ 正确答案 B 回滚只能重新构建全部应用 C 灰度不需要按用户分桶，按流量即可 D 回滚无需考虑契约兼容与缓存残留
# 38. 微前端在 SSR / SSG 下的架构约束（子应用预渲染 vs 客户端水合） A SSR 场景下共享依赖可以双实例运行 B SSR 下子应用预渲染需与客户端水合保持状态与依赖一致，SSR 失败可降级为该片段客户端渲染 ✓ 正确答案 C 服务端渲染的状态无需序列化注入页面 D 子应用 SSR 失败会导致整页 500
# 39. Module Federation 中 React 被配置为 singleton、eager、requiredVersion 和 strictVersion 的不同组合时，宿主与远程版本不满足 semver 会分别发生什么 A singleton 配置下版本不满足会直接报错 B 版本不满足时非单例自载、单例降级告警、加 strictVersion 报错，eager 提前注册会改变协商时机 ✓ 正确答案 C eager 只影响加载速度，不影响版本协商 D requiredVersion 越精确越安全
# 40. 远程应用把大型共享依赖设为 eager 后，为什么可能破坏异步共享边界并放大入口包 A eager 让共享依赖提前注册进入口，破坏异步协商时序并让每个远程各带一份大依赖，放大入口体积 ✓ 正确答案 B eager 不会影响共享依赖的注册时机 C eager 可以解决共享依赖的版本冲突 D eager 打包不会增加入口体积
# 41. React、Vue 与 Solid 子应用共存时，怎样隔离全局 polyfill、Custom Elements 注册表、CSS reset、事件补丁和 devtools hook，避免后加载技术栈修改先加载应用的运行时行为 A Custom Elements 注册表天然支持同名元素多版本共存 B 多技术栈共存需对 polyfill、Custom Elements、CSS reset、事件补丁与 devtools hook 分别做命名空间或作用域隔离，并做加载顺序组合验证 ✓ 正确答案 C 后加载应用的 CSS reset 不影响先加载应用 D devtools hook 各框架互不干扰，无需处理
