Python反射机制使用注意事项

Python反射机制看似强大，实则充满隐秘陷阱：双下划线私有属性因名称改写而无法直接通过getattr/setattr访问；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) 返回的是元类实例，不是定义时写的类名，打印出来可能让你困惑

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

今天关于《Python反射机制使用注意事项》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！