微前端治理与测试

• 组件测试在子应用内独立执行的边界划分
• 跨子应用的契约测试：接口、事件与共享依赖的契约
• 测试环境编排：mock 边界与集成执行策略

跨子应用测试分两层：组件/单元层在各子应用自己的流水线内执行——子应用独立构建独立测试，mock 掉基座注入的 props 与远程依赖，验证自身行为；契约层在「边界」上执行——子应用暴露的接口（props 契约、事件契约、路由契约、MF 的 exposes/shared 契约）用契约测试固定下来，基座与消费方基于契约 mock 联调。跨子应用集成测试则需要真实组合：测试编排工具（如 Playwright/TestCafe）启动基座与多个子应用的真实产物，执行跨应用用户流程（从子应用 A 跳转到子应用 B、共享状态传递）。执行策略：契约测试进 CI 且阻塞发布（任一端的契约破坏即失败），集成测试在预发环境跑关键路径全集、回归路径做抽样。关键工程点是「契约先行」：先定契约再实现，跨端改动前先跑契约测试。

本题考「测试分层与边界」：组件测试内聚、契约测试卡边界、集成测试验证组合，三层各有执行时机与阻塞级别，回答要体现契约在跨应用协作中的枢纽地位。

• 版本兼容性矩阵：主子应用版本组合的声明与维护
• breaking change 检测：契约测试、API 探测与产物级校验
• 检测结果驱动发布决策的闭环

兼容性矩阵是把「主应用版本 × 子应用版本」的支持组合显式化：每个子应用发布时声明兼容的基座版本范围（及反向），矩阵存储在配置中心或版本元数据中，运行时按矩阵校验，不兼容组合拒绝激活并告警。breaking change 检测的工程机制分三层：契约层——子应用暴露的接口（props、事件、路由、MF exposes）用契约测试与 schema 校验，任一签名变化即标记 breaking；产物层——对构建产物做 API 探测（扫描暴露模块的导出、依赖的 requiredVersion 变化）并对比上次快照，自动识别破坏性变更；运行层——预发环境真实组合跑冒烟，把矩阵无法覆盖的隐性破坏兜住。检测结果接入发布门禁：breaking 变更要求同步升级消费方版本或走显式兼容窗口，否则阻断发布，形成「变更可识别、影响可评估、发布可门禁」的闭环。

本题考治理机制建设：先定义兼容性矩阵（组合显式化），再给三层 breaking 检测（契约、产物、运行），最后落到门禁闭环，强调检测不是为了「发现」而是为了「决策」。

• Design System 的共享方式：npm 包 vs MF exposes vs CDN
• 升级策略：同步升级 vs 多版本共存，及版本漂移治理
• 多版本共存的冲突点：设计 token、全局样式与框架单例

共享方式三种：npm 包（各子应用构建期引入，版本独立、升级按各自节奏，最常用但易产生版本漂移）；MF exposes（组件库作为联邦远程，运行时共享一份实现，升级即时生效但要求强治理与高可用）；CDN external（全局脚本，最统一但失去按需与构建期类型检查）。升级策略核心是「漂移治理 vs 共存成本」的权衡：同步升级（所有子应用在一个窗口内升到同一版本）体验最一致但需要协调各团队；多版本共存（各子应用各自版本）灵活但全局样式、设计 token 与框架单例（若组件库依赖 React 单例）可能冲突，出现「两套主题变量、两套样式重置」互相干扰。工程策略：组件库内部版本化设计 token（--ds-v1-primary 之类）并声明在各自容器边界；跨版本用 Shadow DOM 或 scoped 隔离样式；依赖框架单例的组件库尽量走同步升级；以契约测试锁定「组件 API 兼容范围」，让升级可自动化验证。

本题考「共享与演进的平衡」：先对比三种共享方式，再聚焦升级策略的取舍（同步 vs 多版本共存），最后落到 token 命名、样式隔离与契约测试三类共存治理手段，体现对 Design System 治理的完整思考。

• 主子应用错误边界的层级设计与错误归属
• 性能基线的统一口径（Web Vitals 跨应用聚合）
• 日志聚合的上下文关联（traceId、应用标识）

错误边界分两层：每个子应用内用自己的 ErrorBoundary 捕获渲染错误并降级到本地兜底 UI；基座层提供全局边界捕获未处理异常与跨应用错误，并负责「归属」——异常事件携带来源应用标识（appName、版本、入口路由），配合各自 source map 还原堆栈。性能基线统一指所有应用按同一口径采集 Web Vitals（LCP/INP/CLS）与资源指标，上报携带统一的「当前激活应用栈」（哪几个子应用在页面上），聚合时既能看整体页面基线，也能按应用拆分贡献度，SLA 依据统一口径制定。日志聚合的关键是上下文串联：基座生成或透传 traceId，子应用上报统一携带，前端日志、接口错误与后端 APM 通过 traceId 关联成完整链路；统一 SDK、统一字段规范（版本、环境、应用名），落库后按应用/版本/路由多维聚合，形成监控大盘与告警。

回答按「错误、性能、日志」三条线展开，每条强调「统一口径 + 归属标识 + 关联链路」：错误要归属、性能要拆解、日志要串联，体现可观测性建设的系统性。

• 独立发布的流水线：子应用独立构建、测试、灰度与产物管理
• 联合发版的流水线：版本组合的编排与原子性
• 回滚策略：产物级回滚 vs 配置级回滚

独立发布强调「每个子应用一条流水线」：各自构建、跑契约测试与质量门禁、上传 CDN（版本化目录）、独立灰度（按用户/流量切入口配置），发布风险面只限于自身；回滚是产物级 + 配置级的组合——产物保留历史版本，回滚即把配置中心指向旧版本入口，秒级生效无需重新构建。联合发版用于「必须同时变更」的场景（如接口契约同步破坏、跨应用重构）：流水线按组合编排，先构建全部涉及应用，在预发环境跑联合冒烟，通过后按组合整体灰度、整体回滚，回滚是把整组入口配置切回上一组合快照。策略选择的依据是变更耦合度：低耦合用独立发布（快、自主、风险局部化），高耦合用联合发版（原子、可控）；日常推荐「独立发布为主、联合发版为辅」，并保留组合快照支撑回滚。

本题考发布模型设计：对比两种模式的流水线结构与回滚手段（独立=配置级秒回滚，联合=组合快照原子回滚），最后给出按耦合度选择的决策框架，体现发布治理的工程判断。

• 故障隔离的实现：错误边界、沙箱边界与资源边界
• 崩溃形态：渲染崩溃、JS 全局异常、资源加载失败
• 验证手段：故障注入测试与演练

实现故障隔离靠三类边界：渲染边界——子应用根节点包裹 ErrorBoundary（React）或 errorCaptured（Vue），渲染崩溃时降级到占位 UI，其他应用不受影响；执行边界——沙箱把子应用的全局副作用隔离，崩溃或无限循环不污染宿主与其他应用，未捕获异常由全局 handler 拦截上报而非中断基座主流程；资源边界——子应用资源加载失败（CDN 挂了、remoteEntry 404）时按降级策略处理（重试、本地兜底、路由级 fallback），基座不因某个远程不可用而白屏。验证手段是故障注入：在预发环境人为制造崩溃（抛异常、断网、加载超时、改坏 remoteEntry），验证页面其余部分可用、监控能正确归属告警；把故障注入编成自动化的混沌演练用例，纳入发布门禁与定期演练，确保故障隔离能力不随版本退化。

回答按「三类边界（渲染/执行/资源）→ 降级行为 → 故障注入验证」组织：先讲怎么隔离，再讲如何验证隔离始终有效，突出「故障隔离是需要持续演练验证的能力」。

• 接口契约的版本化策略：URL 版本 vs 协商版本
• CDC 的消费者驱动契约机制与工具链（Pact 等）
• 契约测试在主子应用独立发布中的价值

接口契约管理的核心是「版本化 + 契约测试」：版本化上，对外 API 用 URL 版本（/v1/orders）或请求头协商版本（Accept 版本、自定义头），保证新旧版本可并存、消费方可渐进升级；对内（子应用间、基座与子应用间）重点靠契约约束而非版本堆叠。CDC（消费者驱动契约）把契约定义权交给消费者：每个消费方（子应用）生成对提供方（接口或另一子应用）的调用契约，提供方用契约测试验证自身实现满足所有消费者契约，任何一方变更都先跑契约测试，破坏即阻断发布。工具上 Pact 支持契约的发布/验证流水线，JS 生态常用 Pact JS 做浏览器/Node 契约测试。价值在于：多团队独立发布时，「接口改动是否影响他方」由机器判定而非口头协调，显著降低跨团队集成事故。

本题考契约工程：先讲版本化策略（并存与渐进升级），再讲 CDC 的机制（消费者定义、提供方验证）与工具，最后落到「独立发布场景下的价值」，突出契约测试替代人工协调的治理意义。

• Token 的持有与传递：基座统一持有、存储安全与刷新
• SSO 集成：登录态在主子应用间的同步方式
• 权限同步：用户权限的下发、缓存与失效

鉴权治理的原则是「基座统一、子应用消费」：基座完成 SSO 登录与 Token 管理（存于内存或受限存储，绑定刷新机制），子应用通过 props 或共享通道获取 Token，不在各子应用重复实现登录流程，避免多套登录态互相打架。Token 传递注意安全：优先通过受控注入（props/沙箱内访问）而非 localStorage 明文广播，跨域子应用场景用 HttpOnly Cookie（SameSite 策略）或 iframe postMessage 显式传递，并对子应用做信任分级。权限同步：用户权限在登录/刷新后由基座统一拉取并下发（用户域 → 功能权限 → 路由与按钮级权限），子应用按契约读取并缓存，权限变更通过事件或版本号机制通知子应用刷新，避免「权限已收回但子应用缓存仍旧」的越权窗口。SSO 集成上主子应用共用同一 IdP 会话，子应用独立域时通过认证代理或 token exchange 同步会话，保证跨应用跳转无需重复登录。

回答按「登录态统一（SSO）、Token 安全传递、权限同步与失效」三层组织，突出「基座统一、子应用消费、权限有版本可失效」的治理主线，覆盖安全与体验两侧。

• 性能预算的分类：体积预算、时间预算、数量预算
• 主子应用预算的分配模型与监控回环
• 首屏 SLA 的制定、度量与告警

性能预算分三类：体积预算（子应用 JS/CSS 产物上限）、时间预算（加载、首屏渲染阈值）、数量预算（请求数、第三方脚本数）。落地模型是「总预算 + 分账」：基座规划整体首屏预算（如 3s LCP），按子应用实际激活路径把体积与时间配额分配给各子应用，超预算的构建在 CI 硬性失败或软性告警；每个子应用在流水线中度量自己的产物体积与加载耗时，与预算比对并记录历史趋势。首屏 SLA 的治理闭环：定义可度量的 SLO（如 LCP P75 < 2.5s、激活首屏完整率），用 RUM 数据持续度量（分应用、分版本、分路径），超出基线触发告警与回滚；预算写入 CI 门禁，构建期拦截超标产物；定期评审预算合理性（随网络环境与产品形态调整），避免预算僵化或形同虚设。

回答按「预算分类 → 主子应用分账模型 → SLA 度量闭环」组织，强调预算必须「可度量、可门禁、可回滚」三要素齐全，且是持续治理而非一次性设定。

• 独立运行环境：基座注入能力（props、路由、鉴权）的模拟
• mock 分层：接口层、基座 API 层、远程模块层
• 独立开发与测试一体化的脚手架设计

独立测试的前提是「子应用不知道自己在被 mock」：脚手架提供独立运行入口，模拟基座注入的一切——props（用户、路由、权限、跳转能力）、基座 API（qiankun 的 actions、MF 的 remote）、全局环境（沙箱行为、公共样式）。mock 分三层：接口层 mock 用 MSW 等工具拦截 HTTP，返回契约化数据，契约数据来自 CDC 的契约文件，保证与真实接口一致；基座能力层 mock 提供 props/事件的假实现并记录调用，用于断言子应用是否按契约使用基座能力；远程模块层 mock 把 MF 的 remote 替换为本地 stub 或测试双端，验证共享依赖协商与降级路径。工程上把独立运行入口、mock 配置与测试环境打包进子应用模板（脚手架），开发者本地「无基座可跑、可测」，CI 中同样以该入口跑组件与 E2E，实现开发与测试一体化。

本题考测试基建：先立「契约化 mock」原则（mock 必须与真实契约一致，否则测试失真），再按接口、基座能力、远程模块三层展开，最后落到脚手架化的一体化工程形态。

• 联调环境的组合形态：最新主应用 × 各子应用版本组合
• 环境编排：动态组合、快照与环境锁
• 联调环境的质量保障与成本控制

联调环境解决「真实组合验证」：环境由主应用与一组子应用按版本组合编排而成，组合来源可以是「各自最新稳定版」（日常联调）、「发布候选组合」（发布前验证）或「指定版本矩阵」（复现问题）。搭建方式：配置驱动——环境清单描述每个应用的版本入口（CDN 地址或构建产物），环境服务按清单动态组装，无需重新构建；支持环境锁（一个组合被某团队占用时其他人不可覆盖）避免多团队互相踩踏。管理要点：环境命名规范（按用途：feature/rc/stable）、自动清理与回收、把组合快照持久化便于回滚复现。质量保障上，联调环境承担集成测试全集（跨应用流程、契约验证、故障演练），并通过「每次发布自动在 rc 组合上跑关键路径」保证组合质量；成本控制靠按需拉起、空闲回收与多组合共享公共组件。

本题考环境工程：先讲联调环境的本质（版本组合的运行时验证），再讲配置驱动的动态组装与环境锁，最后落到质量保障（rc 组合自动验证）与成本控制，体现环境管理的工程化。

• 共享依赖的版本组合空间与矩阵维度
• 关键场景：宿主先加载、远程先加载、版本回滚、离线缓存
• 矩阵的自动化执行与结果判定

兼容性矩阵把「共享依赖版本组合」显式枚举：维度包括宿主版本、远程版本、共享依赖版本范围、加载顺序与缓存状态。关键场景四类：宿主先加载（共享依赖实例由宿主提供，远程复用）、远程先加载（远程先于宿主实例化依赖，宿主需复用或协商）、版本回滚（远程回退旧版本后共享协商是否仍成立）、离线缓存（旧 remoteEntry 被 Service Worker 缓存后与新版宿主组合）。每个场景验证的断言：依赖是否单例（React 多实例即 invalid hook call）、版本协商是否按 requiredVersion 命中、上下文是否断裂（Provider 跨应用丢失）。落地方式：矩阵由测试框架从配置生成（笛卡尔积裁剪为有意义的组合），CI 中逐组合执行「加载 - 挂载 - 交互 - 卸载」的冒烟流程，用契约测试断言共享契约，结果按组合维度汇总；发现破坏时锁定「哪两个版本的组合」不兼容，驱动版本治理。

本题考「组合测试」的工程化：先讲矩阵维度与四类关键场景的成因，再讲每个场景的断言重点（单例、协商、上下文），最后落到自动生成与按组合汇总的 CI 落地。

• 冒烟范围的选择：核心业务路径与跨应用流程
• 编排方式：组合环境 + 分级冒烟 + 失败门禁
• 冒烟测试的稳定性与反馈闭环

冒烟编排的目标是「发布前以最小成本验证组合可用」：范围上选择高价值核心路径（登录 → 首页 → 每个子应用的主流程、跨应用跳转、鉴权、全局状态同步），而非全量回归；方式上在 rc 组合环境执行分级冒烟——L1 为每个发布应用独立冒烟（加载、挂载、核心交互），L2 为跨应用组合冒烟（A→B 跳转、共享状态、错误归属），L1 全绿才放行 L2，L2 通过才允许发布。编排要点：用例清单由应用 owner 维护并随发布变更更新；冒烟结果作为发布门禁（失败即阻断）；报告按应用与版本归档，失败自动归属到具体应用的变更；为降低脆弱性，冒烟用例避免依赖动态数据与时间敏感断言，对不稳定环节用契约测试代替 UI 断言。反馈闭环：冒烟失败信息自动关联变更记录，通知对应团队，修复后重跑同一组合。

本题考发布质量门禁：先讲范围选择（核心路径 + 跨应用流程），再讲 L1/L2 分级编排与门禁语义，最后讲稳定性治理与失败反馈闭环，体现「冒烟是流程而非脚本集合」的认知。

• 多 bundle 同名模块（如 common.js、index.js）导致堆栈歧义的问题
• 归属手段：bundle 标识、构建产物清单与 source map 选择
• 归一化：按应用上下文重写与聚合

问题成因：多个子应用的 chunk 命名相似或相同（每个应用都打包出 index.js、chunk-xxx.js），堆栈还原时按文件名匹配 source map 会把错误映射到错误应用的同名模块上。归属与还原的关键是「用 bundle 的唯一标识替代文件名」：构建时给每个产物注入唯一 ID（构建哈希、应用名 + 版本），运行时错误事件携带「来源 bundle 的 URL/ID」，还原服务按该 ID 定位对应应用及 source map，而不是全局按文件名搜索。归一化处理：上报链路中给堆栈追加应用上下文（appName、版本、路由），聚合时先按应用拆分再统一符号化；对共享同名模块（如公共工具库）记录其所属版本快照，避免不同应用的同名文件互相污染堆栈归类。工程落地：构建产物清单（manifest，含 bundle → source map → 应用版本映射）随发布归档，符号化服务以清单为准完成归一化还原。

本题考「多源堆栈的符号化工程」：先讲同名冲突如何造成歧义，再讲以 bundle 唯一标识 + 产物清单替代文件名匹配的归属方案，最后讲上报上下文与聚合归一化，覆盖从采集到还原的完整链路。

• 环境竞争的表现：互相覆盖版本、用例串扰、结果归属混乱
• 隔离手段：环境级隔离、数据隔离与用例隔离
• 环境锁与蓝绿切换：独占窗口与秒级切换

竞争的核心是「多个团队对同一环境的并发写」：A 团队部署了新版本，B 团队的用例跑在混合产物上，失败无法归属。隔离策略分三级：环境级隔离——按团队/分支拉起独立环境（每团队一套组合），彻底消除竞争但成本高；数据隔离——共用环境但数据按团队分命名空间（用户、订单数据前缀区分），避免用例数据互踩；用例隔离——E2E 用例声明所需环境标签，调度器路由到匹配环境。环境锁用于「独占窗口」：团队发布验证期间对组合加锁（如 30 分钟），其他人不得覆盖，锁粒度到组合级；蓝绿切换用于「无感切换」：环境维护蓝绿两套组合，发布方部署到绿、验证完一键切蓝为绿，验证失败立即切回，其他团队始终在蓝侧稳定执行，把「覆盖」变成「切换」并支持即时回滚。

本题考共享基础设施的并发治理：先定义竞争问题（覆盖、串扰、归属混乱），再给三级隔离（环境/数据/用例），最后重点讲环境锁与蓝绿切换如何把竞争变成可控的切换，突出「切换优于覆盖」的设计思想。

• 焦点丢失的成因：切换挂载/卸载、隐藏容器、异步渲染
• 治理：焦点管理契约、焦点归还策略与 inert 边界
• 可访问性回归测试：键盘流程自动化与断言

焦点丢失成因：应用切换时旧应用 unmount 销毁了焦点元素、新应用异步挂载尚未就绪、或容器被隐藏（display:none）导致焦点元素脱离可聚焦上下文，键盘用户 Tab 到边界后焦点「消失」，后续按键失去落点。治理要点：切换协议化——子应用 unmount 时记录焦点锚点（最后聚焦元素或触发元素），新应用挂载完成后把焦点移交到指定入口（如应用标题或首元素）；边界用 inert——未激活子应用容器设 inert，让 Tab 顺序只包含激活应用，避免焦点漫游到隐藏区域；异步渲染用 focus 延迟就绪策略（挂载后再聚焦）。回归测试：用自动化键盘脚本（Tab/Shift+Tab/Enter）走「跨应用切换 + 焦点断言」用例，断言焦点在应用边界切换后的落点（activeElement 归属）与可见性（在视口内），纳入发布门禁；同时配合 axe 等静态可访问性检查补充语义断言。

回答按「成因 → 治理（锚点移交、inert 边界、就绪聚焦）→ 自动化回归」组织，焦点问题本质是「生命周期切换时没有接管焦点」，治理与测试都要围绕切换协议展开。

• 不稳定来源：动画、字体加载、网络资源与异步渲染
• 微前端特有的不稳定：组合环境差异、动态资源
• 稳定性策略：冻结机制、阈值与容差、基线管理

视觉回归的核心问题是「不稳定」（flaky）：同一页面两次截图像素不同导致误报。来源包括动画与过渡（截图时机不同）、字体与图标加载时序（webfont 未就绪）、网络资源（图片、CDN 延迟）、异步渲染（数据未到）、时间相关 UI（时钟、倒计时）。微前端特有挑战：组合环境差异（同一子应用在不同基座组合下布局不同）、动态加载的远程模块时序、跨应用样式边界（scoped 前缀差异）。应对策略：冻结机制——测试前禁用动画（CSS animation 关闭）、等待字体就绪（document.fonts.ready）、固定时间源与 mock 数据；容差设计——像素 diff 用阈值（如 <0.1% 差异忽略）与区域豁免（允许变化的广告位等）；基线管理——基线按应用版本归档，变更先审阅 diff 再更新基线，diff 报告人审闭环；架构上把视觉回归收敛到「稳定的应用组合」而非全量随机组合，提高可复现性。

本题考测试稳定性工程：先分类不稳定来源（通用 + 微前端特有），再给「冻结输入、容差输出、基线治理」三类策略，最后落到组合收敛，强调稳定性是「设计出来」而非「碰运气」。

• 子应用体积预算的设定依据（基线、设备、目标）
• 预算的度量口径与 CI 门禁
• 体积超限的治理流程：拆分、按需、告警回滚

设定依据：先测量现状基线（各子应用 gzip 后体积、加载耗时），按目标设备与网络（如 4G 中端机）推算出允许体积，再按「业务价值 / 体积」给子应用分配配额，通常对框架类依赖统一走 shared 不计入单应用配额。度量口径要统一：产物统计用「子应用自身 chunk 之和（不含 shared 依赖）」，上报与 CI 用同一计算脚本避免口径漂移。门禁落地：CI 构建后计算体积与预算比对，超预算按级别处理——硬性超限（> 阈值 110%）阻断发布，软性超限（> 100%）告警并进入体积治理队列；产物体积趋势写入仪表盘，按版本跟踪。治理流程：超限后优先排查重复打包（依赖未 shared 导致每应用一份 React）、按需加载未生效（路由级拆包）、大库误引（全量引入 UI 库），用打包分析器定位后拆分或改按需，治理后回填预算基线形成闭环。

本题考体积治理闭环：按「设定（基线 + 配额）→ 度量（统一口径）→ 门禁（CI 分级）→ 治理（分析定位修复）」组织，强调口径统一与分级门禁，以及「shared 依赖不计入单应用配额」的微前端特性。

• 接入规范的内容域：生命周期、路由、样式与通信契约
• 规范的可执行化：模板脚手架、lint 与自动检查
• onboarding 流程：从文档到实践的落地路径

文档治理的核心是「规范可执行、知识可沉淀」：接入规范覆盖子应用生命周期契约（mount/unmount 清理要求）、路由前缀与激活规则、样式隔离约定（scoped/shadow 选择）、通信契约（事件命名空间、全局状态读写规则）、鉴权与上报规范（统一 SDK 接入），并以「正反例」形式撰写，让读者直接可对照。最佳实践沉淀为公共模块与模板：脚手架（子应用模板）内置规范——生命周期模板代码、路由配置、监控 SDK、lint 规则（限制全局污染、强制命名前缀），新人接入时「模板即规范」，文档只解释为什么。onboarding 标准化：接入清单（checklist）逐项勾选（跑通加载、样式隔离、鉴权、上报、契约测试），配合示例应用与配套演练；规范变更通过变更日志与升级脚本推动存量子应用对齐，避免规范成为一纸空文。

本题考「工程化知识管理」：先定义规范内容域，再强调「模板脚手架 + lint 把规范变成可执行约束」，最后给 onboarding 清单化与存量对齐机制，体现「文档要能被执行」的治理理念。

• 共享 lint/格式配置的发布与版本管理（config 包）
• CI 门禁的分级：lint、类型、测试、体积、契约
• 接入检查清单：新子应用的合规验收

统一治理的载体是「共享配置包」：把 eslint/prettier/stylelint 与 TypeScript 配置发布为私有 npm 包（如 @team/eslint-config-microfrontend），各子应用引入并锁定版本，规范变更通过升级配置包驱动全体对齐，避免各团队各自为政的规则漂移。CI 门禁分级把关：L0 语法与格式（lint 秒级）、L1 类型检查与单测、L2 契约测试与构建产物检查（体积预算、无重复打包、source map 上传）、L3 集成冒烟与安全扫描，各级在流水线中串行执行，任一级失败阻断合并与发布，门禁规则与阈值由平台团队统一配置下发。接入检查清单用于新子应用合规验收：模板脚手架自动产出「接入自检报告」（规范扫描、监控上报冒烟、契约测试通过率、可访问性基础检查），人工 review 只针对报告外的事项，清单固化在 onboarding 流程中，验收通过才开放正式环境入口。

本题考「治理的工具化落地」：先讲共享配置包解决「规则统一与升级」，再讲 CI 分级门禁解决「自动把关」，最后讲接入清单解决「新应用合规」，三层构成从规则到验收的完整闭环。