Python反射机制的局限与应用技巧

Python反射机制虽强大，却暗藏诸多陷阱：双下划线私有属性因名称改写导致getattr/setattr/hasattr失灵；inspect.signature对partial函数、C扩展及装饰器包装的函数常返回空签名或报错；eval/exec不仅存在严重安全风险，还破坏作用域、难以调试且不跨平台；而type()类型判断易被继承关系误导，应优先使用isinstance()。这些限制提醒我们——反射不是万能胶水，过度依赖会推迟错误暴露、增加追踪难度，真正稳健的代码需在“动态灵活”与“显式可靠”之间谨慎权衡。

getattr 和 setattr 不能绕过私有属性命名约定

Python 没有真正的私有属性，getattr 和 setattr 能读写以单下划线开头（如 _cache）甚至双下划线开头（如 __value）的属性——但双下划线会触发名称改写（name mangling），直接用原名会失败。

• 访问 __value 要用改写后的名字，比如 obj._ClassName__value，而不是 getattr(obj, '__value')
• hasattr 对双下划线属性也可能返回 False，因为它内部调用 getattr 并捕获异常，而改写名不匹配就抛 AttributeError
• 依赖 __dict__ 查看属性时，注意双下划线字段已重命名，别按字面名去搜

inspect.signature 在运行时可能拿不到完整参数信息

不是所有可调用对象都支持准确反射。比如用 functools.partial 包装过的函数、C 扩展函数（如 json.loads）、或被装饰器抹除了 __signature__ 的函数，inspect.signature 会 fallback 到 Signature.empty 或抛 ValueError。

• 检查前先判断：sig = inspect.signature(func); if sig is inspect.Signature.empty: ...
• @functools.wraps 不自动复制 __signature__，装饰器作者需手动设置 wrapped.__signature__ = inspect.signature(func)
• 对内置函数，inspect.signature 可能只返回 (*args, **kwargs)，无法得知真实约束

eval 和 exec 是反射“最后一招”，但危险且不可靠

当动态执行字符串代码时，eval 和 exec 看似灵活，实则破坏作用域隔离、绕过静态分析、难以调试，还容易引入注入漏洞。

• 避免拼接用户输入进 eval，哪怕加了 ast.literal_eval 也仅限字面量，别试图“加强版”它
• exec 创建的变量默认在局部作用域丢失，想保留得显式传入 locals 和 globals 字典，但要注意副作用扩散
• 某些环境（如 PyPy、某些沙箱）可能禁用 eval/exec，或限制其行为，别当成跨平台反射方案

type() 和 isinstance() 在继承链复杂时容易误判

用 type(obj) is SomeClass 判定类型，会漏掉子类实例；而过度依赖 isinstance(obj, ABC) 又可能因注册机制（ABC.register()）导致意料外的匹配。

• 优先用 isinstance(obj, SomeClass)，除非你明确需要排除子类
• 自定义抽象基类时，register() 是手动关联，不改变 MRO，isinstance 仍能识别，但 issubclass 不会返回 True
• 元类创建的类，type(obj) 返回的是元类实例，不是定义时写的类名，打印出来可能让你困惑

反射不是万能胶水，它把“知道什么”和“能做什么”的边界推得更远，但也让错误更晚暴露、更难追踪。最常出问题的，是假设某个属性一定存在、某个签名一定可读、或者某个类型检查一定符合直觉——而这些恰恰是运行时才决定的事。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~