核心思路是避免在父类构造器中访问子类字段，因子类字段尚未初始化；应采用两段式构建：先创建对象，再通过setup()等显式方法完成依赖自身状态的初始化。
核心思路不是“抢在父类构造器前初始化子类字段”，而是让子类字段根本不在构造过程中被访问——因为语言规范决定了：父类构造器执行时，子类字段尚未初始化，这是不可绕过的事实。
明确初始化阶段边界，不混淆“声明默认值”和“实例初始化”
很多开发者误以为给字段写 private String name = "default"; 就等于“已安全初始化”。其实不然：这个赋值动作发生在父类构造器执行完毕、进入子类字段初始化阶段时。若父类构造器里调用了 toString() 或 init() 这类可重写方法，此时 name 仍是 null（引用类型）或 0/false（基本类型）。
- 把字段声明为 final 并用字面量/常量初始化（如 final int version = 1;），该值会在字段初始化阶段被确定，但依然无法解决方法内访问逻辑依赖问题
- 避免在字段声明处做复杂计算（如 private List<String> items = new ArrayList<>();），这虽能防止 null，但若重写方法中又调用了 items.add(...)，仍可能因对象状态不一致引发并发或 NPE
- 真正安全的做法是：字段只声明，不赋值；所有有意义的初始化推迟到构造完成后的显式入口
用“两段式构建”替代“构造即就绪”惯性思维
放弃“new 一个对象就立刻可用”的假设，主动拆分对象生命周期为 创建 和 准备 两个阶段。
- 父类构造器只做最低限度的事：分配内存、设置 final 字段、调用 super()、记录传入参数（如 id、config）
- 提供一个非 final、可被子类重写的 void setup() 方法，由使用者在 new 之后手动调用：obj.setup();
- 子类在 setup() 中完成字段赋值、资源加载、回调注册等依赖自身状态的操作
- 可在父类中加防护：若 setup() 未被调用就访问关键字段，抛出 IllegalStateException
借助编译期约束封死危险调用路径
光靠文档和约定不可靠，要让错误在编码阶段暴露。
- Java：将父类中被构造器调用的方法声明为 final（如 final void validateConfig() { ... }），子类无法重写，自然规避风险
- C#：父类方法不加 virtual，或子类重写后加 sealed override，阻止进一步继承链污染
- Python：虽无语法限制，但可配合 mypy 类型检查 + 自定义 lint 规则，扫描构造器内对非私有方法的调用，标记为高危
- IDE 配合：IntelliJ / VS Code 安装插件（如 SonarLint），启用 “Constructor calls overridable method” 检查项，实时标红提醒
验证是否真已杜绝隐患的实操检查点
每次新增继承结构后，快速过一遍这几条：
- 父类构造器里有没有直接或间接调用任何 public/protected 方法？如果有，这些方法是否都加了 final 或等效修饰？
- 子类中是否存在重写父类方法且内部访问了本类非 final 字段的行为？若有，该方法是否只在 setup() 或后续业务方法中被调用？
- 测试用例是否覆盖了“new 子类 → 立即调用其重写方法 → 检查字段值”这一路径？结果是否符合预期（比如不为 null，不为默认初值）？
- CI 流水线是否集成了静态分析工具，自动拦截含此类模式的 PR？
