monkeypatch.setenv修改后os.getenv仍返回旧值，根本原因是配置模块已在导入时缓存环境变量，后续monkeypatch无法刷新该缓存；正确做法是提前设置或改用setattr/reload。
monkeypatch.setenv 为什么修改后 os.getenv 仍返回旧值
常见现象是调用 monkeypatch.setenv("FOO", "bar") 后，紧接着执行 os.getenv("FOO") 却得到 None 或原值。根本原因是：Python 的 os.environ 是一个字典代理对象，它在首次导入时会缓存环境变量快照；而 monkeypatch.setenv 只修改了 os.environ 字典本身，并不会触发底层 C 层的 getenv() 缓存刷新（尤其在某些 Python 版本或嵌入式环境中）。更稳妥的做法是直接操作 os.environ 并确保后续读取走的是该字典。
正确用法：优先直接赋值 os.environ，再用 monkeypatch 清理
Pytest 的 monkeypatch 主要用于测试中临时修改、自动还原，不是通用环境变量设置工具。实际操作应分两步：先手动设值保证生效，再用 monkeypatch 确保测试结束自动清理。否则容易出现“改了但没完全改”的情况。
-
os.environ["FOO"] = "bar"—— 立即生效，os.getenv("FOO")和os.environ.get("FOO")都能读到 -
monkeypatch.setenv("FOO", "bar")—— 本质等价于上一行，但会在测试退出时自动del os.environ["FOO"]（若原不存在）或恢复原值（若原存在） - 若需删除变量，用
monkeypatch.delenv("FOO", raising=False)，raising=False避免因变量原本不存在而报KeyError
os.environ 与 subprocess.Popen 的环境继承关系
子进程是否能继承新设的环境变量，取决于你是否显式传入 env 参数。默认情况下，subprocess.Popen 会复制当前 os.environ，所以只要你在调用前已通过 os.environ["FOO"] = "bar" 或 monkeypatch.setenv 设置好，子进程就能看到。但注意：
- 不要混用
os.putenv()—— 它只影响底层 C 环境，不更新os.environ字典，导致 Python 层读不到，子进程也大概率继承不到 - 如果调用
Popen(..., env=custom_env)，则完全忽略os.environ，此时必须手动把所需变量注入custom_env -
monkeypatch.setenv对已启动的子进程无效，只影响后续创建的进程
测试中覆盖已有变量的兼容性陷阱
当被测代码在模块顶层就调用了 os.getenv("DEBUG")（比如配置加载逻辑），那么 monkeypatch.setenv 在测试函数里调用已经太晚——值早已被缓存。这时必须在 import 前设值，或改用 pytest --env=DEBUG=1 配合插件，或重构为延迟读取（例如封装成函数调用而非模块变量）。
立即学习“Python免费学习笔记（深入）”；
另一个坑是大小写：Windows 下环境变量名不区分大小写，但 os.environ 字典键仍是原始大小写；Linux/macOS 则严格区分。用 monkeypatch.setenv("Path", "xxx") 在 Windows 上可能意外覆盖 PATH，建议统一用大写标准名。
真正麻烦的从来不是怎么改，而是改完谁在什么时候、以什么方式去读它——尤其是跨模块、跨进程、跨语言调用时，os.environ 的一致性远比想象中脆弱。
