__init__ 中不应做耗时资源获取，因其导致构造失败风险外溢、阻塞调用方且难以区分创建与使用失败；应将资源获取移至独立方法、__enter__/__aenter__ 或 __post_init__，并提供 is_ready 状态标识。
为什么 __init__ 里不该做耗时资源获取
因为这会让对象构造失败风险外溢、阻塞调用方，且无法区分“创建失败”和“使用失败”。比如数据库连接、HTTP 请求、大文件读取，一旦网络抖动或磁盘忙，__init__ 就抛异常，而调用者往往没准备捕获——毕竟“new 一个对象”在直觉上不该出错。
实操建议：
- 把资源获取逻辑拆到独立方法（如
connect()、load_data()），显式调用 - 在
__init__中只存配置、路径、参数等轻量状态，不触发 IO 或网络 - 若必须懒加载，用
property+if not hasattr(self, '_resource')或functools.cached_property（Python 3.8+） - 注意：多线程下
cached_property非线程安全，高并发场景需自己加锁
__enter__ 和 __aenter__ 是更自然的资源初始化入口
当你需要“创建即可用”，又不想让 __init__ 承担副作用，上下文管理器是更符合 Python 惯例的选择。它天然绑定生命周期，也强制用户考虑清理。
常见错误现象：手动写 obj.init(); obj.do_something(); obj.close() —— 容易漏掉 close，尤其遇到异常时。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 把资源获取放进
__enter__，释放放进__exit__；异步用__aenter__/__aexit__ - 避免在
__enter__中做不可逆操作（如删临时目录），否则with块没执行完就崩溃，状态可能残留 - 如果资源初始化可能失败，
__enter__抛异常是合理行为，with会自动跳过__exit__的清理逻辑，这点比手动init更可控
用 __post_init__（dataclass）替代 __init__ 做轻量预处理
当用 @dataclass 时，__init__ 被自动生成，你没法直接插逻辑；但 __post_init__ 是专为“字段已赋值、但对象还没完全就绪”设计的钩子。
使用场景：校验字段组合、计算派生属性、标准化输入格式（如把 path 字符串转成 Path 对象）。
注意点：
-
__post_init__不该做 IO，它仍属于构造阶段，和__init__同样受“构造应快”的约束 - 如果 dataclass 有
init=False字段，它们在__post_init__里才可安全访问（因为__init__不会设它们） - 继承时，父类
__post_init__不会自动调用，需显式写super().__post_init__()
资源型类该有明确的“已就绪”状态标识
用户需要知道对象能不能用了。靠文档说“调用 connect() 后才能用”不够可靠，运行时也没法检查。
实操建议：
- 加一个只读属性
is_ready，内部检查关键资源句柄是否非空/有效（如self._conn is not None and self._conn.open） - 在关键方法开头用
if not self.is_ready: raise RuntimeError("Resource not initialized")，比静默失败或神秘AttributeError友好得多 - 避免用
try/except AttributeError来探测状态——这掩盖了设计问题，也慢 - 如果资源可重连，
is_ready应反映当前实时状态，而不是“曾经成功过”
最麻烦的地方其实是边界交叉：比如一个类既要支持同步初始化，又要兼容 asyncio，还得能被 pickle。这时候别硬塞进一个构造函数，拆成 SyncClient 和 AsyncClient 两个类，反而更清晰。没人规定资源类必须长得一样。
