Java抽象类通过编译期强制拦截直接实例化，以语言机制保障领域模型抽象安全性；其禁止new实例是编译器级硬约束，无论是否有抽象方法，只要声明abstract即不可实例化，且需配合final字段与构造参数确保不可变性及契约完整性。
Java 抽象类通过 编译期强制拦截 直接实例化，从语言机制层面保障核心领域模型的抽象安全性——它不是靠文档约定或运行时检查，而是让 new AbstractClass() 这样的代码根本无法通过编译。
禁止 new 实例是编译器级硬约束
只要类声明了 abstract 关键字，JVM 字节码规范和 Java 编译器（javac）就明确禁止生成调用其构造器的指令。哪怕构造器是 public，哪怕类里没有任何抽象方法，只要带 abstract 修饰符，new MyDomainModel() 就会报错：
- 错误提示清晰：「Cannot instantiate the type MyDomainModel」
- IDE 实时标红，无需单元测试或代码审查就能拦截
- 该限制作用于所有上下文——主函数、测试类、反射调用（
Class.newInstance()或Constructor.newInstance()均抛InstantiationException）
抽象性不依赖“有没有抽象方法”
很多团队误以为“必须写 abstract 方法才算抽象”，其实恰恰相反：一个纯提供默认行为、无任何 abstract 方法的抽象类，反而是领域模型抽象安全性的最强表达。例如：
-
abstract class Order可以封装订单编号生成、状态流转校验、时间戳赋值等通用逻辑，但不允许出现“一个泛化的订单实例” - 子类如
OnlineOrder、ReturnOrder才代表真实业务实体，各自定义差异点（如支付方式、退货原因） - 这种设计堵死了“创建空订单”、“伪造基础订单对象绕过校验”等常见领域建模漏洞
配合 final 字段与构造参数加固不可变性
仅靠 abstract 不足以防止子类破坏抽象契约。需结合构造阶段的确定性初始化：
立即学习“Java免费学习笔记（深入）”；
- 关键领域标识字段（如
final String orderId）必须在抽象父类构造器中完成赋值，且只接受参数传入或使用安全默认值（如UUID.randomUUID()） - 避免在构造器中调用子类可重写的方法（如
init()），否则会导致 this 逃逸和字段未初始化问题 - 依赖项（如验证器、仓储接口）应通过构造参数注入，而非子类自行 new 或延迟初始化
抽象类作为领域分层的锚点
在 DDD 分层架构中，抽象类天然适合作为 domain 层的基类锚点：
- 它能持有 protected 的领域状态（如
protected LocalDateTime createdAt），interface 无法做到 - 它可定义 package-private 方法供同包内聚合根协作，不对外暴露实现细节
- 它支持模板方法模式——把不变的领域规则（如“创建订单必须校验库存”）固化在
final方法中，仅开放abstract钩子给子类定制
