1. 触发器精细化：别让「每次 push 都跑全家桶」
on: 可组合事件与过滤条件：
- branches / branches-ignore：只对 main、release/* 跑完整 CI。
- paths / paths-ignore：改 README 不跑构建；改 src/** 才跑。
- pull_request types：opened, synchronize, reopened 等，避免无关 activity 触发。
- concurrency：同一 PR 只保留最新一次 run，节省分钟数。
提示：pull_request 的工作目录是「合并基线」上的临时 merge commit；与直接 push 到分支的行为略有差异，排障时要分清。
图 1：触发 = 事件 AND 分支 AND 路径（可扩展 types）。过滤越准，成本与噪声越低。
2. 分支保护 + Required checks：把「绿」变成「能合并」
在仓库 Settings → Branches 配置 protection rules（如 main）：
- Require status checks：指定 workflow job 名作为合并门槛；与 workflow 里 name: 一致。
- Require pull request reviews：最少人数、CODEOWNERS。
- Require linear history / squash：按团队规范选择。
- Do not allow bypass：限制管理员跳过（治理关键）。
图 2：合并是「检查结果 + 分支策略」的合取；Required checks 名称需与 workflow job 对齐。
3. permissions：GITHUB_TOKEN 最小化
在 workflow 或 job 级设置 permissions:。常见模式：
- 只读构建：contents: read。
- PR 机器人评论：pull-requests: write（按需）。
- 发布 Release：contents: write（配合 tag 规则）。
高危：pull_request_target 在默认分支上下文运行且可访问 secrets——仅用于受控场景（如 label 触发后），切勿直接 checkout PR 恶意代码并执行。
图 3：显式 permissions 缩小 token 能力面；写权限集中在少数 job（如 deploy），与读分离。
4. Environments：生产部署的另一道门
environment: 可绑定 protection rules：required reviewers、wait timer、deployment branches。 适合把「能合并 main」与「能触发生产部署」分开——与第 18～21 章 CD 治理一致。
5. 最小清单
- main 开 branch protection + required checks。
- 每个 workflow 写 permissions；deploy job 单独收紧/放宽。
- 用 paths 过滤减少无效 run；concurrency 控队列。
- 慎用 pull_request_target；fork 贡献走标准 PR + hosted runner。