github actions 的 secrets 上下文通过 ${{ secrets.name }} 在 workflow 文件中引用，需映射为环境变量供 c# 读取；仓库/组织级 secret 在 settings 配置，名称区分大小写；c# 应用 environment.getenvironmentvariable 安全获取，禁用日志打印、硬编码或配置文件存储。
GitHub Actions 的 secrets 上下文怎么用
GitHub Actions 里不能把密码、API Key 这类敏感数据写死在 .yml 文件里，必须通过 secrets 上下文注入。它只在运行时可用，且不会被日志打印出来（除非你主动用 echo ${{ secrets.MY_SECRET }} 这种方式泄露）。
实操要点：
-
secrets只能在 workflow 文件中通过${{ secrets.SECRET_NAME }}引用，不能在 C# 代码里直接读取这个表达式——它不是环境变量，只是 YAML 模板语法 - 真正传给 C# 程序的，得靠 GitHub Actions 把 secret 映射成环境变量，例如：
env:<br> API_KEY: ${{ secrets.API_KEY }} - 仓库级 secret 在 Settings → Secrets and variables → Actions 下配置；组织级或环境级 secret 需对应权限才能看到和使用
- 注意大小写：secret 名称是区分大小写的，
MyApiKey和myapikey是两个不同 secret
C# 项目中如何安全读取 GitHub Actions 注入的机密
C# 本身没有“自动加载 GitHub secrets”的机制，必须依赖外部传入。最稳妥的方式是走环境变量 + Environment.GetEnvironmentVariable，而不是硬编码、配置文件或命令行参数（后者容易被 ps aux 或日志捕获）。
推荐做法：
- 在 workflow 中显式设置 env 变量，避免用
run: dotnet build --configuration Release /p:MyApiKey=${{ secrets.MY_API_KEY }}这类方式，MSBuild 属性可能意外暴露在构建日志里 - C# 代码中统一用
Environment.GetEnvironmentVariable("MY_API_KEY")获取，返回null时应视为配置缺失并快速失败，不要 fallback 到默认值 - 如果用到
IConfiguration（如 ASP.NET Core），确保AddEnvironmentVariables()被调用，且 secret 名称与环境变量名一致（比如My__Api__Key对应MY__API__KEY） - 避免在异常消息中拼接 secret 值，哪怕只是部分字符——
throw new InvalidOperationException($"Auth failed for key: {key.Substring(0, 4)}...")仍可能泄露前缀
为什么不能把机密写进 appsettings.json 或 .gitignore 里的文件
有人会想：“我把 appsettings.Production.json 加进 .gitignore，然后手动上传到 runner”，这非常危险。
问题在于：
- GitHub Actions runner 是临时实例，每次 job 启动都是干净环境，你没法“上传”文件过去（除非用
actions/upload-artifact+download-artifact，但这反而增加泄露面） -
.gitignore只阻止提交，不阻止误操作。一旦某次git add -f或编辑器自动保存，secret 就进了仓库历史，删都删不干净 - CI 流程中若用
dotnet user-secrets，它底层依赖本地文件系统（%APPDATA%\Microsoft\UserSecrets\...），而 GitHub-hosted runner 不保留该路径，且无法预置 - 自建 self-hosted runner 也不能依赖本地文件存 secret——机器可能被重装、复用，或多人共享，违背最小权限原则
常见错误：日志泄露、权限错配、本地调试断层
这些坑往往在上线后才暴露，但根源都在 workflow 写法和 C# 适配逻辑里。
典型现象和对策：
- CI 日志里出现明文 key：检查是否用了
set -x、bash -x或pwsh -Command "Write-Host $env:API_KEY"—— 所有含$env:或$的打印语句都要删掉 - 本地开发能跑，CI 报
NullReferenceException：确认 workflow 中 env 键名和 C# 读取的字符串完全一致，且该 secret 已在仓库正确配置（拼写、空格、下划线都算差异） - 用了
with:传参给某个 action，但该 action 内部把输入当普通字符串打印了：查该 action 的源码或文档，确认它是否对输入做脱敏；不放心就改用 env 注入 - 在
if: ${{ secrets.DB_PASSWORD != '' }}这类条件判断里直接引用 secret——GitHub 不允许在if表达式中使用secrets，会静默跳过整个 job 步骤
C# 侧真正要做的其实很简单：只从环境变量读、不缓存、不打印、不 fallback。复杂点全在 GitHub Actions 配置层——命名一致性、注入时机、作用域控制，这些稍有疏忽，机密就可能从缝隙里漏出去。
