对象构造未完成前调用其方法或访问字段会导致未定义行为，因内存布局不完整、final字段未写入、虚表未就绪；应通过日志验证调用时序，将高危操作移至start/init方法，使用工厂模式确保返回已就绪实例，并辅以状态校验与静态检查。
构造函数还没跑完，就去调用它的方法、访问它的字段，甚至把它传给别的模块——这不是语法错误，但会直接触发未定义行为。核心问题在于：对象处于“半初始化”状态，内存布局可能不完整，final 字段还没写入，虚表尚未就绪，线程看到的可能是零值、脏数据或崩溃信号。
识别是否真发生了提前调用
别猜，要验证：
- 在构造函数第一行和最后一行加日志，比如 log("ctor begin", this) 和 log("ctor end", this)
- 在所有被怀疑被提前调用的方法入口也打日志，比如 log("onEvent called", this)
- 如果“onEvent called”出现在“ctor end”之前，说明调用确实发生在构造完成前
- 特别注意监听器注册、回调绑定、线程启动、异步提交这些动作——它们常把 this 偷偷送出去
检查构造函数里的高危操作链
很多提前调用不是明写的，而是藏在调用栈深处：
- 构造函数调用了 initListeners()，而该方法内部注册了 source.addListener(this::handle) —— 这里 this::handle 就捕获了未完成的对象
- 用了 lambda 或匿名类，比如 executor.submit(() -> doWork())，只要里面引用了成员变量或非 static 方法，就等于把 this 提前发布了
- 第三方框架自动注入，像 Spring 的 @Autowired 字段在构造函数执行中可能已被填充，但此时对象还没构造完，其他 Bean 拿到的就是“残缺实例”
修复的关键不是堵漏洞，而是改时机
把“必须等构造完才能做的事”，从构造函数里拎出来，交给明确的生命周期节点：
- 提供一个 public void start() 或 public void init() 方法，把监听注册、线程启动、资源绑定全挪进去
- 工厂方法统一管控：构造私有化，工厂里先 new，再 init，最后返回，确保使用者拿到的是“已就绪”对象
- 对必须持有当前对象引用的外部系统，改用 WeakReference 或延迟解析（比如用 Supplier
替代直接传 this） - Java 中关键状态字段全部声明为 final，并在构造函数参数列表中一次性赋值，避免后续修改带来的可见性风险
运行时加固与兜底手段
即使代码逻辑正确，也要防住误用和框架干扰：
- 在敏感方法开头加状态校验，例如 if (!initialized) throw new IllegalStateException("not ready")
- C++ 中可在构造函数末尾设置一个原子标志位，所有对外暴露的方法都先检查它
- 启用编译器/IDE 静态检查：Clang 的 -Wunsafe-buffer-usage、SpotBugs 的 SE_BAD_FIELD_ACCESS、IntelliJ 的 “Thread Safety Inspection” 都能抓出典型模式
- 单元测试中模拟并发场景：在构造函数中插入短延时，另起线程立刻调用目标方法，看是否 crash 或读到默认值
