pytest-env本身不提供脱敏能力，仅负责设置环境变量；明文密码注入进程会导致CI日志、堆栈等泄露，真正防泄露需让测试代码只处理占位符，真实密钥由CI Secrets运行时注入且不落地。
直接结论：pytest-env 本身不提供脱敏能力，它只负责设置环境变量——而把明文密码塞进环境变量，等于在CI日志里主动贴标签“请记录我”。真正防泄露的关键动作是：不在任何地方加载原始敏感值，也不让它们进入进程环境。
为什么 pytest-env 不能解决敏感信息泄露
pytest-env 的作用仅限于读取 pytest.ini 或命令行参数中的键值对，然后调用 os.environ.update() 注入进程。一旦你写 env = DATABASE_PASSWORD="my_real_password"，这个字符串就会出现在 CI 日志、失败堆栈、甚至 ps aux 进程列表中。
- 它不校验值是否含敏感字段（比如
"password"、"key"、"token"） - 它不支持运行时占位符替换（如
${DB_PASSWORD}→ 实际由 CI secret 注入） - 它不阻止
os.environ被repr()打印——而 pytest 默认的错误回溯会这么做
正确做法：让 fixture 只认占位符，真实值绝不落地
所有测试代码（包括 fixture）必须假设环境变量里只有脱敏标识，例如 "DB_PASSWORD=REDACTED"，而不是真实密码。真实值由 CI 系统（如 GitHub Actions secrets、GitLab CI variables）在运行时注入，且不写入任何配置文件或日志。
- 在
conftest.py中定义 fixture 时，只从os.getenv("DB_PASSWORD")读值，但立刻检查是否为"REDACTED"或空字符串 - 若检测到占位符，抛出自定义异常
ConfigRedactedError("DB_PASSWORD not provided by CI")，其__str__不拼接原始值 - CI 流水线中用
env:块注入真实值：DB_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}，该值不会出现在 job 日志中
避免踩坑：pytest-env 配置里的三个高危写法
以下写法看似方便，实则直接暴露密钥：
立即学习“Python免费学习笔记（深入）”；
-
env = API_KEY="${API_KEY}"——${...}是 pytest-env 的变量引用语法，但它仍会把API_KEY的当前值（可能来自本地.env）注入，而非等待 CI 注入 -
env = DATABASE_URL="mysql://user:real_pass@host/db"—— 字符串硬编码，git commit 后永远留在历史里 -
env = D:SECRET_KEY=${SECRET_KEY}——D:前缀只防覆盖，不防泄露；若本地已设SECRET_KEY，它照样被注入并打印
真正安全的配置只有一行：env = DB_PASSWORD=REDACTED，且该行仅用于本地开发兜底，CI 中完全忽略它。
最后提醒：环境变量不是保险箱，而是玻璃管道
只要敏感值经过 Python 进程内存，就可能被 traceback.format_exc()、logging.getLogger().exception()、甚至 pytest --capture=no 输出捕获。所以核心原则不是“怎么藏好”，而是“根本别让它进来”——让测试代码永远只处理占位符，把真实值隔离在进程之外。这比任何插件配置都关键。
