直接修改 __class__ 会破坏实例内存布局，极易触发 TypeError；典型错误包括 __slots__ 不匹配或新旧类结构不兼容；赋值成功也不保证行为正常，因 __init__ 不重执行、方法查找走新类但属性仍属旧实例；推荐用策略模式替代，更安全可测。
直接修改 __class__ 会破坏实例的内存布局，极大概率触发 TypeError: __class__ assignment: 'OldClass' object layout differs from 'NewClass'，不是“能不能”，而是“改了就可能崩”。
__class__ 赋值失败的典型错误场景
报错最常见于两类情况：
- 旧类或新类中任意一方定义了
__slots__，但两者声明的 slot 名称列表不完全一致（缺一个、多一个、拼写错都不行） - 旧类没用
__slots__，但新类用了——此时新类拒绝接收旧实例已有的、未在__slots__中声明的属性 - 两个类都用了
__slots__，但字段名顺序不同没关系，内容必须严格相同
改完 __class__ 后方法调用不生效？
赋值成功 ≠ 行为如预期。关键点有三个：
-
__init__不会自动重跑：新类的初始化逻辑不会触发，实例状态仍是旧类构造时留下的 - 方法查找走新类：后续调用
obj.method()会从新类的__dict__查，但属性仍保留在原实例上（只要没被 layout 冲突拦住） - 继承链断裂风险：如果新类不是旧类的子类，且代码里有
isinstance(obj, SomeBase)判断，结果会变成False
想换行为，为什么不用策略模式代替？
90% 的动态换类需求，其实是要切换行为逻辑，而非硬切类型。策略模式更安全、可测、易调试：
立即学习“Python免费学习笔记（深入）”；
- 把不同行为封装成独立类，实例持有一个
strategy属性，运行时替换该属性即可 - 避免触碰底层对象结构，不依赖
__class__这种 CPython 实现细节 - 类型检查工具（如 mypy）能正常识别，IDE 自动补全不丢
- 单元测试可针对各策略单独覆盖，无需 mock 类型切换过程
真正需要改 __class__ 的场景极少，比如 ORM 框架内部做懒加载代理、或某些极端元编程。普通业务代码里，看到 obj.__class__ = X 就该警觉——它大概率是设计缺陷的临时补丁，而不是优雅解法。
