禁止在构造器中派发业务事件，因此时对象为“半成品”，final字段未写入、子类字段为默认值，易致状态错乱、空指针或竞态；应改用init()等显式生命周期方法，并封禁继承链中this外泄路径。
在高度抽象的领域模型继承体系中，this 指针本身不会“失控”，真正失控的是对 this 的误用时机与传播路径——尤其当它被提前暴露、跨线程引用或在未完成初始化时触发事件派发。这类问题不报编译错误，却会在运行时引发状态错乱、空指针、竞态条件甚至业务逻辑跳变。
禁止在构造器中派发业务事件
这是最直接的根源。父类或子类构造器里调用 eventBus.publish(this)、notifyListeners() 或注册回调，等于把一个“半成品对象”交给了外部世界。
- final 字段可能尚未写入，JVM 不保证其可见性
- 子类字段仍为默认值（
null、0、false），但事件监听器已开始消费 - 若监听器调用
this.calculate()等方法，而该方法依赖未初始化的子类状态，结果不可预测
用显式生命周期方法替代隐式构造触发
把事件派发从构造流程中剥离，转为由使用者明确控制的阶段行为：
- 构造器只做字段赋值、校验参数、创建内部组件（如
new HashMap()） - 新增
init()或activate()方法，统一负责：注册监听、加载配置、发布“已就绪”事件 - 若需框架集成（如 Spring），用
@PostConstruct替代构造器内操作；注意它仍属初始化阶段，不能早于依赖注入完成
在继承链中封禁 this 外泄路径
深度继承下，this 逃逸常藏在看似安全的父类方法调用中：
- 父类构造器调用
setupListeners()，而该方法在子类中被重写并传this给异步队列 → 危险 - 基类提供模板方法
onCreated()，子类实现时启动线程并传this::handle→ 危险 - 解决方案：父类中所有可能触发外泄的方法（如
register()、start()）声明为final；子类定制逻辑通过策略对象注入，而非重写
用值捕获代替 this 引用传递
当必须在事件中携带上下文信息时，避免直接传 this，改用不可变快照：
- 构造完成后，提取关键业务标识（如
orderId、tenantId）、状态枚举、时间戳等，封装为EventContext对象 - 监听器基于这些值查询完整对象（如从仓储获取），而非持有原始引用
- 既规避逃逸风险，又支持事件重放、跨服务解耦
不复杂但容易忽略：this 不是 bug 的源头，而是失控信号的放大器。真正要约束的，是对象何时、以何种形式进入协作网络。
