变量按环境作用域是什么
变量按环境作用域（environment scope）指同名变量在不同环境取不同值：GitLab 的变量支持 environment scope（可精确匹配或通配，如 review/*），GitHub 的 environment 级 variables/secrets 同名时覆盖仓库级。这样一套作业定义就能用环境名切换配置来源，不必为每个环境复制一份作业。使用要点是两个：作用域名必须与 environment 名称一致，否则静默取到默认值；默认值应指向安全（非生产）环境，避免匹配失败时误连生产。
基本信息
| GitLab | 环境作用域（environment scope）可为不同环境配不同值，支持通配 |
|---|---|
| GitHub | environment 级 variables/secrets 覆盖仓库级同名项 |
| 收益 | 一套流水线用环境名切换配置来源 |
| 匹配 | 作用域名与 environment 名精确一致；通配规则仔细核对 |
典型使用场景
- 同一作业多环境部署：API 地址、bucket、区域等按环境取不同值。
- 凭据分隔：生产凭据只在 production 作用域配置，其他环境取不到。
- 受保护环境配合：生产作用域叠加环境保护规则，限定可部署角色与审批。
- 临时环境：用通配作用域（如 review/*）给预览环境套通用变量。
- 审计清晰：作用域让「谁能拿到什么」在平台里直接可见。
GitLab 场景
GitLab 场景
变量 API_URL：
- scope staging → https://staging.example.com
- scope production → https://www.example.com
# GitHub：environment 级 variables/secrets 同名覆盖仓库级平台对照
| 平台 | 机制 | 覆盖关系 |
|---|---|---|
| GitLab | 变量 environment scope | 按作用域匹配取用 |
| GitHub | environment variables/secrets | 环境级覆盖仓库级 |
作用域命名与 environment 名称保持一致：命名漂移会让作用域匹配失败，变量静默回落到默认值。
默认作用域的值要设计成安全环境：匹配失败时宁可用错也不要用到生产参数，默认值指向 staging 而不是生产。
排查「变量不生效」的顺序：先核对作业所在 environment 与变量作用域是否一致，再确认优先级（环境级覆盖仓库级），最后检查保护规则是否拒绝授权。