CODEOWNERS 是什么
CODEOWNERS 是把评审责任绑定到目录的配置文件：为路径指定默认评审人，改动命中该路径时自动请求对应负责人评审。它与分支保护配合可以要求「必须由代码负责人批准」才能合并，从而把「谁该看这段代码」从口头约定变成可执行的规则。
基本信息
| 文件位置 | 常见于仓库根目录、.github/ 或 docs/ 目录 |
|---|---|
| 匹配规则 | 按行从上到下匹配，最后命中的规则生效 |
| 可指定的对象 | 个人账号或团队，需要具备仓库的写权限 |
| 配合规则 | 开启「需要代码负责人批准」后才具备强制力 |
CODEOWNERS 示例
CODEOWNERS 示例
# 按最后匹配生效；顺序从通用到具体
* @team/core
/docs/ @team/docs
/payment/ @team/payments @alice
*.proto @team/api编写要点
- 顺序从通用到具体：最后匹配的规则生效，具体路径写在后面。
- 责任落到小组或具体的人：owner 团队过大等于没有 owner。
- 高风险目录必须有明确负责人（支付、权限、数据迁移脚本）。
- 配置文件本身也要有 owner：随意放宽规则等于降低整库门槛。
- 定期清理：团队重组后及时更新，避免请求发给已解散的团队。
- 新增目录要同步登记：新模块如果没被规则覆盖，会默认漏掉负责人。
- 规则放宽必须走评审：CODEOWNERS 的修改等同于调整整库的门槛。
- 每年核对一次 owner 与团队分工：人员变动后不更新，责任会落到已离开的人身上。
常见配置问题
| 问题 | 后果 |
|---|---|
| 规则顺序写反 | 具体路径被后面的通配符规则覆盖 |
| 指向过大的团队 | 无人觉得是自己的责任，评审被搁置 |
| owner 离职未更新 | 请求无人响应，改动长期挂着 |
| 只配文件不配目录 | 新增文件不命中规则，自动漏掉负责人 |
owner 团队过大等于没有 owner：维护责任要落到具体小组或个人身上。
不同平台的语法细节有差异（路径写法、是否支持章节分组）：迁移仓库时要重新核对规则是否仍按预期生效。