如何在Python中使用pytest的monkeypatch修改全局变量？

monkeypatch.setattr 不能直接改模块级变量，因为模块级变量是命名空间绑定名而非对象属性；正确做法是传入模块对象和变量名字符串，如 monkeypatch.setattr(mymodule, 'DEBUG', True)。

说真的，很多开发者第一次用 monkeypatch 改全局变量时，都会掉进同一个坑里。明明照着文档写，却报错说“模块没有这个属性”。别急，问题出在 monkeypatch 的“脾气”上——它只认对象属性，不认模块命名空间里的绑定名。简单说，字符串路径 'mymodule.DEBUG' 在 monkeypatch 眼里是在找属性，而不是全局变量。所以正确的姿势是：把模块对象本身传进去，再告诉它变量名。

import mymodule

def test_with_global_var(monkeypatch):
    monkeypatch.setattr(mymodule, 'DEBUG', True)  # ✅ 正确：传模块对象 + 变量名
    assert mymodule.DEBUG is True

修改内置模块变量（如 os.environ）要小心作用域

说到 os.environ，这是另一个重灾区。很多人图省事，直接用 monkeypatch.setattr 替换整个 os.environ 字典。结果测试一跑，系统变量全没了，连 PATH 都丢了。这显然不是你想要的效果。更稳妥的做法是只改单个键值，保留其他环境变量。

• ✅ 推荐做法：用 monkeypatch.setitem(os.environ, 'MY_VAR', 'test') —— 只动一个键，不影响全局
• ⚠️ 千万别这样：monkeypatch.setattr(os, 'environ', {'MY_VAR': 'test'}) —— 等于清空所有环境变量，后果自负
• ? 注意：setitem 只对 mapping 类型（dict、os.environ）有效，普通模块变量不适用

patch 模块级常量时，导入方式影响 patch 效果

这里有个隐藏很深的陷阱：如果被测代码写的是 from mymodule import DEBUG，那么哪怕你成功 patch 了 mymodule.DEBUG，测试代码里引用的 DEBUG 依然是原来的值。因为导入后，DEBUG 已经变成了当前模块的局部变量，跟原模块再无瓜葛。

怎么破？只有两条路可选：

• ✅ 在被测代码所在的模块里 patch —— 直接改“使用方”模块的 DEBUG 名称
• ✅ 改用绝对导入路径：在测试中写 monkeypatch.setattr('target_module.DEBUG', 'new_value')，这里的 target_module 是实际使用该变量的模块名，不是定义它的模块
• ❌ 别去 patch 定义模块，除非被测代码用 import mymodule + mymodule.DEBUG 方式访问

临时修改 sys.path 或其他不可变全局状态

对 sys.path 这类可变对象，monkeypatch 依然可以替换，但更安全的做法是直接用 monkeypatch.setattr(sys, 'path', new_path_list)。好消息是，pytest 会在每个测试结束后自动恢复 sys.path，所以你不需要手动清理。但要注意顺序：如果测试里要 import 依赖修改后的路径，务必在 patch 之后再 import，monkeypatch 是函数作用域，顺序就是生命线。

对 sys.argv 同理，但建议不要在 fixture 里提前 patch，否则容易被其他测试干扰。最后提醒一句：monkeypatch 的生命周期只到测试函数结束，别指望在 fixture 里 patch 就能跨测试生效——每个测试都是独立的，不存在“全局临时修改”这种美事。