secrets 与 vars 怎么分工
GitHub Actions 把配置分成两类：secrets 存敏感值（凭据、令牌），引用为 ${{ secrets.NAME }}，运行时注入并在日志里自动打码；vars 存非敏感的普通配置（区域、域名、开关），引用为 ${{ vars.NAME }}。两者都支持组织 / 仓库 / 环境三级，同名时更靠近作业的一级生效（环境优先于仓库、仓库优先于组织）。环境级配置与环境的保护规则联动：配了审批要求的环境，只有审批通过后作业才能拿到对应 secrets，适合把生产凭据与预发凭据分开管理。secrets 不能直接写在 if 条件表达式里，需要条件判断时先赋给 env 再引用。
基本信息
| secrets 引用 | ${{ secrets.NAME }}，日志自动掩码 |
|---|---|
| vars 引用 | ${{ vars.NAME }}，普通配置 |
| 层级 | 组织 → 仓库 → 环境，就近覆盖 |
| 条件判断 | secrets 不能直接用于 if，先赋给 env |
| 环境联动 | 环境级 secrets 受环境保护规则约束 |
典型使用场景
- 注入部署凭据：registry token、云厂商访问密钥放 secrets，workflow 文件里不出现明文。
- 多环境区分：staging 与 prod 各配环境级 secrets，同名不同值，作业引用方式不变。
- 普通参数集中管理：区域、实例规格、通知频道 ID 放 vars，调整时不用改动 workflow。
- 组织级共享：多个仓库共用同一套镜像仓库与通知配置时放组织级，减少逐仓库维护。
- 替代长期密钥：云上优先用 OIDC 换取短期凭据，secrets 里不再存长期访问密钥。
- 轮换演练：定期轮换 secrets 并跑一遍流水线，避免到期当天才发现依赖它的作业全挂。
经 env 使用
经 env 使用
env:
REGION: ${{ vars.REGION }} # 普通配置直接引用
steps:
- run: deploy --region $REGION
env:
TOKEN: ${{ secrets.REGISTRY_TOKEN }} # 敏感值经 env 注入
- if: env.TOKEN != '' # 条件判断走 env 变量
run: echo token-readysecrets 与 vars 对比
| 维度 | secrets | vars |
|---|---|---|
| 内容 | 凭据、令牌等敏感值 | 区域、开关等普通配置 |
| 日志显示 | 自动掩码 | 原样显示 |
| 条件表达式 | 不能直接用于 if | 可直接用于 if |
| 环境保护 | 环境级受审批规则约束 | 同样支持三级 |
| 轮换要求 | 定期轮换并演练 | 随配置管理惯例 |
打码不是万能保护：掩码只对原值生效，把秘密编码、拼接后再输出仍可能泄露，调试输出前先确认内容。
Fork 仓库的 PR 默认拿不到 secrets：外部贡献者的作业只应跑无凭据部分，需要凭据的步骤放在可信事件里执行。
环境级 secrets 的价值在保护规则：没配审批与限制分支的环境，作用等同于仓库级。