最直接有效的做法是父类构造函数只调用private或final方法，因为此时子类字段尚未初始化，调用被重写的方法会读取默认值（null/0/false），导致确定性失效而非偶发bug。
最直接有效的做法是：父类构造函数里只调用 private 或 final 方法，其他一律不碰。
为什么这是生产级风险
这不是偶发 bug，而是对象初始化阶段的确定性失效：
- 父类构造器执行时，子类字段尚未初始化（哪怕写了
private String foodName = "肉";，这行赋值也发生在父类构造器返回之后） - 此时若调用被重写的方法，该方法访问子类字段，读到的是默认值（
null、0、false），不是未定义，而是“明确错的值” - 线上环境可能表现为：配置加载为空、连接池初始化失败、状态机进入非法状态——错误延迟暴露，排查成本极高
四条落地防护策略
1. 语法锁死：所有构造器内调用的方法必须加 final
- Java 中声明为
final void init() { ... }，子类无法覆盖，编译期即拦截 - C# 对应
sealed override或初始就不标virtual - Python 虽无语法强制，但可在方法名前加双下划线（
__setup）并配合 mypy 类型检查禁用重定义
2. 逻辑拆分：把多态行为移出构造器
- 构造器只做三件事：字段默认赋值、基础对象分配、必要参数校验
- 把需子类定制的逻辑（如资源加载、回调注册、状态预热）放到独立方法中，例如
public void start()或protected abstract void onReady() - 由使用者明确调用：
new Child().start();，时机可控，字段已就绪
3. 工厂封装：用静态工厂替代 new
- 隐藏构造过程，强制走初始化流程：
Child.create(config) - 工厂内部先
new Child()，再立即调用init()或setup() - 可统一注入监控、超时、重试等生产保障能力
4. 编译+CI 双重拦截
- 在构建流程中加入静态检查规则（如 ErrorProne 的
ConstructorInvokesOverridableMethod） - Git Hook 或 CI 阶段扫描所有
public/protected非final方法是否出现在构造器中 - 发现即阻断，不给“先上线再改”的侥幸空间
别信这些伪解法
以下做法看似合理，实则无效：
- 在子类构造器第一行写
super()—— JVM 规范保证：子类字段初始化总在super()返回之后 - 给子类字段加默认值（
int x = 0;）—— 默认值写入和构造器执行不在同一语义阶段，仍可能被绕过 - 靠文档或 Code Review 提醒 —— 大型项目中没人逐行核对构造器调用链，必须靠机制兜底
