企业微信 Secret 不应直接写在代码文件或配置库中，最推荐的做法是通过环境变量或云厂商密钥管理服务动态加载。适用场景为所有服务端应用，风险边界在于一旦 Secret 提交至版本控制系统，必须视为已泄露并立即轮换。
先说结论：硬编码 Secret 属于高危行为，必须移除代码库并使用外部注入方式管理密钥。
- 先判断：检查 Git 历史记录是否已包含 Secret，若已提交需立即轮换。
- 优先做：将 Secret 迁移至环境变量或密钥管理服务，代码改为动态读取。
- 再验证：确认新 Secret 生效且旧 Secret 失效，同时检查日志无明文输出。
命令速用版
不同语言读取环境变量的方式不同，以下是常见语言的快速读取示例：
Python: os.getenv("WECom_SECRET")
Java: System.getenv("WECom_SECRET")
Node.js: process.env.WECom_SECRET
Go: os.Getenv("WECom_SECRET")若使用 Docker 部署，可在 docker-compose.yml 的 environment 字段注入，避免写入镜像层。
为什么会这样
硬编码 Secret 会导致密钥随代码公开，版本控制系统无法彻底清除历史记录。
企业微信 Secret 用于获取 access_token，拥有调用企业微信接口的权限。一旦泄露，攻击者可冒充企业身份发送消息或获取通讯录数据。代码仓库即使设置为私有，也存在权限泄露或被协作人员误操作公开的风险，且 Git 历史记录保留所有变更，单纯删除代码文件无法清除历史提交中的 Secret。
分步处理
第一步：移除现有硬编码。
在代码中搜索 Secret 关键字，替换为环境变量读取函数。不要直接删除配置文件就提交，需确保新逻辑已生效。
第二步：配置密钥注入。
在服务器操作系统、CI/CD 流水线或容器编排平台中设置环境变量。例如在 Linux 服务器使用 export 命令，或在 Kubernetes 中使用 Secret 对象挂载。
第三步：轮换旧密钥。
登录企业微信管理后台，生成新的 Secret 并更新到环境变量，观察业务是否正常。确认无误后，在后台停用或废弃旧 Secret。
第四步：清理历史记录。
若 Secret 已提交至 Git，使用 git filter-branch 或 BFG Repo-Cleaner 工具清洗历史记录，并强制推送覆盖远程仓库。
怎么验证是否生效
检查运行中的进程环境变量，确认无明文 Secret 残留。
使用命令 cat /proc/[pid]/environ 查看进程环境（Linux 环境）。尝试使用旧 Secret 调用企业微信 API，预期应返回错误码。检查应用日志，确保没有打印 Secret 字段。
常见坑
将包含 Secret 的 .env 文件提交至代码库。建议将 .env 加入 .gitignore 文件。
在异常日志中打印包含 Secret 的请求参数。需在日志脱敏配置中增加 Secret 字段过滤。
前端代码调用后端接口时透传 Secret。Secret 仅应在服务端存储，前端不应接触任何 Secret 信息。
常见问题
Secret 已经泄露到公网怎么办？
立即在企业微信管理后台轮换 Secret，旧 Secret 会失效。
可以使用配置文件存储 Secret 吗？
可以，但配置文件必须排除在版本控制之外，且文件权限需限制为仅运行用户可读。
环境变量会被泄露吗？
风险较低，但需确保服务器权限管理严格，避免未授权访问服务器查看进程环境。
参考来源
企业微信开发者文档，鉴权指引，work.weixin.qq.com