抽象类不能被直接实例化，根本原因是abstract关键字触发编译器语法级禁止，无论构造方法是public还是protected，new操作均在编译期报错“Cannot instantiate the type”，而protected仅控制子类对初始化逻辑的合法调用。
抽象类本身就不能被直接实例化，这是 Java 编译器的硬性规则，和构造方法的访问修饰符无关。protected 构造方法不用于“阻止实例化”，而是用来控制谁可以参与初始化过程——它确保只有子类能调用该构造逻辑，同时防止同包内非子类代码绕过继承关系去干扰初始化。
为什么 abstract 类不能 new，跟 protected 无关
只要类声明为 abstract，哪怕构造方法是 public，编译器也禁止使用 new 创建其实例。这不是运行时检查，而是语法层面直接报错：“Cannot instantiate the type XXX”。所以限制“外部直接实例化”的根本原因是 abstract 关键字，不是 protected。
protected 构造方法的实际作用
它解决的是“谁能在子类构造中调用父类初始化逻辑”这个问题：
- 子类构造器中必须通过 super(...) 显式或隐式调用父类构造方法；设为 protected 后，只有继承链上的子类（以及同包内其他类）能调用，但同包非子类通常不会、也不应去继承无关抽象类，因此实际效果是“仅子类可用”
- 如果构造方法是 public，虽不影响抽象类不可实例化的事实，但会削弱设计意图：外部类可能误以为这个抽象类“可被友好调用”，IDE 或静态分析工具常会警告
- 配合 final 字段，可强制子类在构造时提供必要参数，保证对象创建即满足不变性。例如：protected DataSource(String url, String user) { this.url = url; this.user = user; }
典型写法与常见错误
正确方式是让抽象类只提供带参的 protected 构造，并在其中做参数校验：
立即学习“Java免费学习笔记（深入）”；
- 子类构造器第一行必须写 super(...)，否则编译失败（尤其当父类无无参构造时）
- 不要给抽象类加 public 构造方法——语义混乱，且可能误导协作者
- 避免只留一个 protected 构造却忘记声明 abstract：那样类就变成普通类，可被实例化，失去约束力
和 private 构造的区别
private 构造会让子类也无法继承（编译报错 “Cannot access ...”），所以不适合抽象基类；而 protected 正好卡在这个平衡点：既不允许外部随意调用，又明确开放给子类使用，符合“模板基类”的定位。
