GitHub Actions 密钥管理：上线前检查这五处

自动发布博客需要AI与GitHub凭证。本文提供配置文件、日志、工作流权限和备份的检查顺序，避免把密钥随源码或文章一起同步到公开仓库。

自动发布会接触AI密钥、搜索服务密钥和GitHub令牌。把这些值直接写进源码，虽然启动方便，却会把后续分享源码、截图和备份变成泄露入口。管理密钥应纳入上线检查，而不是出问题后再补。

检查配置文件与提交范围

本地真实配置放在.env中，仓库提供的是空值示例.env.example。忽略规则应覆盖真实配置、数据库和私有备份。提交前查看实际待提交文件列表，不能因为写了.gitignore就假定历史提交中没有密钥。

如发现曾经提交过真实密钥，应先撤销并更换凭证。仅删除当前文件不能让历史副本失效。不要把新的凭证发到公开issue里确认，也不要将完整配置截图作为部署成功证明。

检查工作流和日志

为自动任务提供完成工作所需的最小权限。文章生成任务不应默认获得整个账号范围的管理能力。公开文章、网页HTML和日志中都不应输出服务令牌。调试时优先记录服务名称、状态码、任务编号和耗时，避免打印完整请求头。

在GitHub Actions中使用平台的Secrets配置。平台可能对部分敏感值进行日志遮盖，但不能因此允许脚本随意输出秘密。将密钥嵌入大段JSON或拼接后的字符串，会增加人工检查日志的难度。

检查备份与人员交接

数据库、私有环境文件和公开文章的备份应分开处理。给编辑人员的文章包，不需要包含服务器登录信息。部署教程列出变量名和获取位置即可，不填入实际凭证。

交接时写清楚每个密钥的用途、授权范围、轮换负责人和故障处理步骤。恢复备份后先验证权限与服务连接，再开启自动发布，防止旧配置指向错误仓库。本文是一套上线检查方法，不表示已经审计你的GitHub账号或服务器。

参考资料与适用范围

GitHub：Secrets概念

PHP：密码哈希参考

本文为原创方法教程，不包含未经运行的性能测试结论。示例地址和命令需要替换为你自己的环境；官方服务与界面可能更新，操作前应复核当前文档。资料核对日期：2026年10月7日。