Django测试中使用call_command时为何错误mock会跨用例残留影响后续测试

触发逻辑拆解 #

这个问题是两个容易被忽略的机制叠加出来的：Django管理命令的全局加载缓存，加上错误补丁路径导致的模块引用错位。
完整的执行链路是这样的：

1. test_a启动执行，首先通过@patch('first_app.class_a.method_to_call_from_command')打补丁，把first_app.class_a模块里定义的method_to_call_from_command函数临时替换成一个Mock对象。
2. 紧接着test_a执行call_command('this_is_command', item='test')——这是这个命令在测试进程里第一次被调用，Django会实时加载first_app.management.commands.this_is_command模块。模块加载时会跑顶层的import语句from first_app.class_a import method_to_call_from_command，这时候因为class_a里的这个函数已经被替换成Mock了，命令模块的全局命名空间里，绑定的method_to_call_from_command就是这个Mock对象，而不是最初的真实函数。
3. test_a跑完后，patch的自动清理逻辑会把class_a模块里的method_to_call_from_command还原成原始的真实函数，但它完全感知不到：自己当初替换用的那个Mock对象，已经被命令模块长期持有引用了。这个脱离了补丁上下文的旧Mock，就成了跨测试用例的残留对象。

test_b的异常来源 #

等test_b启动：

• 它正确给first_app.class_a.method_to_import打了补丁，替换成mock_obj2。
• 再次调用call_command时，Django根本不会重新加载命令模块，直接拿第一次加载时缓存的Command类执行。这时候Command的handle方法里调用的method_to_call_from_command，是命令模块自己存的那个test_a残留的旧Mock，根本不是class_a里现在的真实函数。
• 因为调用链从第一步就拐去了孤立的旧Mock，自然不会走到真实的method_to_call_from_command逻辑，也就不会触发method_to_import的调用，最终表现为mock_obj2的call_args为None，预期的打印日志也完全不出现。

为什么几个规避方法能解决问题 #

• 注释掉test_a里的call_command：test_a执行全程都不会触发命令模块的第一次加载，等test_b执行时第一次加载命令，此时test_b的补丁已经生效，加载命令时拿到的是正确的真实函数，自然不会有残留引用。
• 把test_a的补丁路径改到命令模块内部：补丁直接打在first_app.management.commands.this_is_command.method_to_call_from_command上，test跑完清理补丁时，会直接把命令模块里的这个属性还原回真实函数，从根源上避免了旧Mock的残留。

避坑提醒 #

• 打Mock补丁的目标永远是对象被实际使用的命名空间，而不是对象的定义位置：比如命令模块里已经import了method_to_call_from_command，就应该直接给命令模块里的这个引用打补丁，不要去改class_a里的原始定义，否则很容易出现模块间引用错位的问题。
• Django的管理命令模块是全局单例缓存的，跨测试用例的模块状态会一直保留，不会因为测试用例切换就自动重置。

内容的提问来源于stack exchange，提问作者zcahfg2