本文详解为何直接使用 `@patch` 无法拦截类属性中提前执行的函数调用，并提供可靠方案：结合 `patch.object` 与 `importlib.reload` 在模块重载前替换目标函数，确保类属性和实例属性均能响应 mock。
在 Python 单元测试中，当一个函数在类定义阶段（即模块导入时）被直接调用并赋值给类属性（如 class_attribute = bar()），该调用会在任何测试装饰器（如 @patch）生效前就已完成。这是因为类体代码在模块首次被 import 时即执行，而 unittest.mock.patch 的作用时机是在测试方法运行前动态替换命名空间中的对象——此时 Foo.class_attribute 已固化为 "bar" 字符串，后续 patch 对其完全无效。
要真正改变类属性的初始值，必须在类被定义之前就让 bar() 返回期望的 mock 值。核心思路是：
- 先 patch 目标函数对象本身（而非其引用路径），确保所有后续调用都受控；
- 重新加载依赖该函数的模块（如 foo.py），触发类的重新定义，使 class_attribute 重新执行 bar() 并获取 mock 返回值。
以下是可直接运行的修复示例：
# test_foo.py
import importlib
import unittest
from unittest import mock
import foo
import methods # 注意：需显式导入被 patch 的源模块
class FooTestCase(unittest.TestCase):
def test_mock_class_attribute_at_definition_time(self):
expected = "patched foo"
# 关键：patch methods 模块中的 bar 函数对象，并 reload foo 模块
with mock.patch.object(methods, "bar", return_value=expected):
importlib.reload(foo) # 重新执行 foo.py → 重新定义 Foo 类
# 此时 class_attribute 和实例属性均使用 mock 返回值
self.assertEqual(foo.Foo.class_attribute, expected)
self.assertEqual(foo.Foo().class_attribute, expected)⚠️ 注意事项：
立即学习“Python免费学习笔记（深入）”；
- 必须 import methods（而非仅 from methods import bar），因为 patch.object 需要操作模块对象本身；
- importlib.reload(foo) 会重新执行 foo.py 全局代码，包括类定义，因此需确保 foo 模块无副作用（如重复注册、全局状态变更）；
- 若 foo.py 依赖其他未被 reload 的模块，应一并处理其依赖关系，避免状态不一致；
- 此方案适用于单元测试隔离场景，不推荐在生产代码中频繁重载模块。
总结：类属性中“立即求值”的函数调用属于模块加载期行为，mock 必须前置到该阶段之前。patch.object + importlib.reload 是解决此类问题的标准模式，它从根源上重置了类的定义上下文，而非仅拦截运行时调用。
