题干与适用场景
多个团队共同维护仓库，安全、支付和数据目录需要明确的责任人。请说明如何用 CODEOWNERS 配合分支保护或规则集，实现可发现、可执行、可审计的审批流程，并处理例外和团队变更。
面试官考察点
- 是否区分 CODEOWNERS 的自动请求与分支保护中的必需审批。
- 是否核对代码所有者的写权限、可见团队、目标分支和文件位置。
- 是否能处理 CODEOWNERS 自身保护、fork、草稿 PR、规则绕过和审批陈旧。
- 是否用覆盖率、合并阻断率、等待时间和审计记录衡量治理效果。
回答前需要澄清的问题
- 哪些目录必须阻断合并，哪些只需要通知？是否存在紧急修复路径？
- 责任人是个人还是团队？团队可见性、写权限和成员轮换如何维护？
- 保护哪些分支？规则集与经典分支保护是否同时存在？谁可以绕过，绕过是否留痕？
- 如何处理 CODEOWNERS 文件本身、fork、草稿 PR、审批陈旧和离职成员？
30 秒回答框架
我会先绘制关键目录与责任团队，再把 CODEOWNERS 当作匹配和通知层，把分支保护或规则集当作合并阻断层。验证所有者具备写权限、团队可见且文件位于目标分支；保护 CODEOWNERS 自身，定义紧急绕过和审计。上线前用模拟 PR 覆盖新增、移动、删除和 fork 场景，监控审批等待、阻断率、绕过次数和孤儿路径。
分步骤深入解答
1. 定义责任边界
按风险和变更频率划分目录，避免用一个全局团队覆盖所有文件。每条模式都应有明确 owner、备用 owner 和失效时间，定期检查没有匹配者的路径。
2. 分离请求与强制执行
CODEOWNERS 会在相关文件被修改时自动请求审核，但只有启用必需 code owner review 的分支保护或规则集才会阻止合并。把两层分别测试，避免“收到通知”被误认为“无法合并”。
3. 保护配置与例外
把 CODEOWNERS 放在受保护位置，并为它指定 owner。对紧急修复定义最小权限绕过、理由字段和事后复核；处理草稿 PR、fork 和新推送导致审批陈旧的情况。
4. 运营指标与迁移
先在报告模式审计匹配率、孤儿路径、等待时间和误阻断，再逐步开启必需审批。团队成员变更和仓库迁移时同步更新权限、规则集和审计查询，保留回滚方案。
高质量示范回答
我会先按风险划分目录和责任团队，建立带备用 owner 的 CODEOWNERS，并检查团队可见性和写权限。然后明确 CODEOWNERS 负责匹配与通知，分支保护或规则集负责真正阻断合并；两层都用模拟 PR 验证。CODEOWNERS 文件自身放在受保护目录并指定 owner，紧急绕过采用最小权限、理由和事后复核。上线先报告模式测量孤儿路径、误阻断和等待时间，再逐步强制执行；持续监控陈旧审批、绕过次数和规则覆盖，并在成员或分支变化时复核。
常见错误
- 认为 CODEOWNERS 自动请求审核就一定会阻止合并。
- 忽略团队必须可见且拥有写权限。
- 没有保护 CODEOWNERS 自身，导致治理规则可被单独修改。
- 忽略目标分支、fork、草稿 PR 和陈旧审批。
- 没有定义紧急绕过、事后复核和审计留痕。
- 只看审批数量，不看孤儿路径、等待时间和误阻断。
追问及应对
多个 owner 是必须全部批准吗？
通常任一匹配 owner 的批准即可满足 code owner review，除非另有规则。产品设计应明确高风险目录是否需要额外的多方审批规则。
为什么要保护 CODEOWNERS 文件本身？
否则贡献者可以先修改所有权映射，再修改关键代码，绕过原本的责任边界。为配置文件指定 owner 并要求审批能减少这条绕过路径。
如何降低轮换成员造成的阻断？
使用可见团队而非个人，设置备用团队和变更检查；成员离职或权限变化时自动审计孤儿路径，并在规则生效前完成替换和回归 PR。