Python中如何优雅的实现代码与敏感信息分离？

昨天晚上十一点多吧，我在公司楼下抽烟，手上还拿着半杯冰美式，那会儿我们组小李突然在群里嚎了一句：哥，线上又报错了，提示“鉴权失败”，我第一反应不是查代码，是先问他一句：你是不是又把 token 写死在代码里提交了……他沉默了三秒，然后回我一个“啊这”。你们懂吧，这种事儿，谁没干过一两次，尤其赶进度的时候，先跑起来再说，结果跑着跑着就跑到事故里去了。

我后来就顺着这事儿跟他说，代码和敏感信息分离这事儿，别搞得像“安全团队的要求”，它其实是“你未来少背锅”的保险。你想啊，密码、AK/SK、DB 连接串、第三方回调密钥，这些东西一旦进了仓库，哪怕你后来删了，git 历史里也还在，真要较真，基本等于“你在墙上写过”……而且还有个更烦的：你本地能跑，到了测试/预发/生产就挂，因为每套环境不一样，你写死的那套配置根本不适配。

我一般会先让他们把“配置入口”统一掉，别到处 os.environ.get()，到处 open('xxx.conf')，最后你自己都找不到是谁读了哪个值。就搞一个 settings.py，所有敏感东西只从环境变量来，缺了就直接启动失败，别默默给默认值，默认值最坑，表面跑了，实际连到测试库了你还以为是生产……（别问我怎么知道的）

比如最基础的写法，纯标准库就够用了：

然后你业务代码里就别再碰敏感信息了，全部从 load_settings() 拿，传进去，哪怕你不爱传参，也至少集中在一个地方，不要散落到各个模块里。像这样：

你们注意到没，敏感信息都不出现在仓库里了，仓库里只有“名字”，比如 DB_DSN 这种 key。那值放哪？最常见的就是环境变量。开发机上你可以用 .env 文件方便点，但 .env 一定得进 .gitignore，这点我一般会在 code review 里盯死。我们之前就有人把 .env 提上去过，里面还有生产的短信密钥，后来安全那边拉了个表把人吓得一晚上没睡。

如果你嫌自己写校验太土，或者项目里本来就用 pydantic，那就上 pydantic-settings，体验会好一点，尤其是类型检查和默认值策略清晰。大概像这样（我随手写的，思路是这个）：

然后你就 from settings2 import settings，但我个人有点强迫症，生产环境我不太爱全局单例，怕测试不好写、也怕初始化时机不受控。我们之前遇到过一个坑：单测导入模块的时候就把 settings 初始化了，结果 CI 里没配 env，测试直接全挂，排查半天才发现是“导入即读取配置”。所以更稳妥还是“延迟加载 + 显式注入”，当然你们团队怎么舒服怎么来。

再往上走一点，环境变量也不是万能的。比如你在 k8s 里用 Secret 挂载，或者云上用密钥管理（AWS Secrets Manager、GCP Secret Manager、Vault 之类），核心都一样：应用拿到的是“运行时注入的值”，不是仓库里的字面量。你可以把“读取策略”抽一下，开发用 .env，生产用“密钥服务”。我写过一个很土但挺好用的接口，类似这样：

然后 settings 里用 provider 取值：

你看，这样一来，业务代码完全不关心你到底是环境变量、k8s secret、还是 vault。线上切方案也不动业务逻辑，最多换个 provider。说白了就是“依赖倒置”那套东西，但我跟小李说的时候没用这些词，我就说：别让业务代码知道密码从哪来，知道越少越安全，也越好改。

还有个小细节，很多人忽略：日志别把敏感信息打出来。你明明已经把密钥从代码里挪走了，结果启动的时候 print(settings) 一下，日志里全是 secret……那不就白忙活了嘛。我们一般会做个简单的脱敏函数，打印配置只打印是否存在或者前后两位：

对了，还有那个“轮换”问题，很多人一开始不在意，等真要换密钥了才发现代码里写死了缓存，重启才能生效，半夜三点你去不去？我一般会把配置读取放在启动阶段固定住，密钥轮换靠外部方案（双密钥、灰度、版本号），别指望应用热更自己“聪明地”轮换，搞不好更乱。当然你要真想做热加载，也行，记得加版本控制和回滚，不然就是给自己挖坑。

反正那天我在楼下抽完烟回去，小李把那段写死 token 的代码删了，然后他问我：哥，那我 .env 里写什么？我说你写“占位符”都行，比如 DB_DSN=__REPLACE_ME__，关键是别把真的扔进去还提交了……他说懂了懂了，结果第二天我一看他提交记录，.env.example 写得还挺像回事儿，嗯，行吧，先这样，我这会儿还得去把我自己的 CI 配置改一下，不然今晚又要被@了，先不说了哈。

以上就是“Python中如何优雅的实现代码与敏感信息分离？”的详细内容，想要了解更多Python教程欢迎持续关注编程学习网。