抽象类即使没有抽象方法，只要用abstract修饰就禁止实例化，其设计意图是作为带默认实现的模板，用于统一构造逻辑、共享字段或封装受保护行为，并防止误用基类。
抽象类即使没有抽象方法，只要加了 abstract 修饰符，就禁止被 new 出来——这不是疏漏，而是设计意图。它本质是“带默认实现的模板”，用来统一构造逻辑、共享字段或封装受保护的行为，同时防止用户误用基类。
为什么允许无抽象方法的抽象类存在
Java 明确支持这种写法：一个类声明为 abstract，但所有方法都有具体实现。它的作用不是“留空待填”，而是“限制直接使用”。常见动机包括：
- 强制子类继承并定制，哪怕只是调用 super() 初始化公共状态
- 提供可复用的 protected 工具方法或共享字段（比如日志器、配置对象），又不希望外部直接 new 一个“半成品”
- 预留未来扩展点——今天没抽象方法，明天加一个也不破坏现有子类
- 配合框架约束（如 Spring 的 AbstractController），让开发者必须继承而非直接实例化
遇到 “Cannot instantiate the type Xxx” 怎么办
报错说明你写了类似 new BaseService() 这样的代码。解决方向不是绕过限制，而是确认使用意图：
- 如果你需要一个可用对象 → 找或写一个继承该抽象类的非 abstract 子类，确保它没遗漏抽象方法（即使父类没定义）
- 如果只是想复用其中的工具方法 → 把这些方法抽成 static 工具类，或改用组合（has-a）而非继承（is-a）
- 如果该抽象类本就只用于被继承 → 检查调用点，把 new 改成子类名，比如 new UserServiceImpl()
匿名内部类是一种临时解法，但要谨慎用
当抽象类确实没有抽象方法，且你只需要一个一次性实例时，可以用匿名内部类：
立即学习“Java免费学习笔记（深入）”；
BaseService service = new BaseService() {}; // 空大括号即可
但要注意：
- 这本质上创建了一个隐式子类，仍需满足所有构造器可见性（比如父类构造器是 private 就不行）
- 不适合长期持有或注入场景，会增加类加载负担和调试复杂度
- 若抽象类将来加了抽象方法，这段代码立刻编译失败——属于脆弱设计
设计建议：明确抽象类的定位
写抽象类前先问自己：
- 这个类是否天然不该有实例？比如 “动物” 不是一个实体，而“狗”才是
- 它是否提供了子类必须共用的初始化逻辑（如连接池 setup、上下文预热）？
- 它的字段或方法是否只对子类有意义，对外部使用者暴露反而造成误解？
满足任一条件，用 abstract 就合理；否则，考虑普通类 + 私有构造器 或静态工具类更合适。
