抽象方法不能用private修饰，因为private导致子类无法继承和重写，与抽象方法强制子类实现的语义直接冲突；其可见性必须满足多态调用链，接口中默认public，抽象类中可为public或protected，但不可为private或包私有。
抽象方法为什么不能用 private 修饰
因为私有方法无法被子类继承，而抽象方法存在的唯一目的就是强制子类实现它——两者逻辑直接冲突。
Java 的继承机制决定了 private 成员只在本类可见，子类连签名都看不到，更谈不上“重写”。抽象方法又不允许有方法体，不重写就无法实例化，整个继承链就断了。
-
private abstract void run();编译直接报错：Illegal combination of modifiers: 'private' and 'abstract' - 哪怕你绕开语法检查（比如用反射强行调），运行时也无法触发多态分派——根本没地方挂上去
- 如果真想隐藏实现细节，应该用
protected或包级私有 + 具体方法封装，而不是在抽象层堵死访问路径
abstract 方法的可见性必须满足多态调用链
抽象方法最终要通过父类引用调用子类实现，所以它的声明位置必须让调用方和实现方都能“看见”。
也就是说：声明抽象方法的类（通常是抽象类或接口），和未来继承/实现它的类，必须能在同一访问域里互相引用该方法签名。
立即学习“Java免费学习笔记（深入）”；
- 接口中的抽象方法默认是
public，且只能是public—— 因为接口天生面向实现者开放 - 抽象类里的抽象方法可以是
public或protected，但不能是private或default（包私有）除非子类在同一包内 - 跨包继承时，
protected抽象方法在子类中可被重写，但在包外通过父类引用调用会受限——这不是语言限制，而是设计意图提醒：你可能需要public
常见误操作：用 private 尝试“保护抽象契约”
有人想把抽象方法设成 private，以为能防止外部乱调用，其实完全搞反了方向。
抽象方法不是给外部直接调的，它是定义契约的“钩子”，靠子类实现后，再由父类统一调度逻辑。真正该控制访问的是调用入口，不是契约本身。
- 错误做法：
private abstract void initConfig();→ 编译失败，且暴露设计混乱 - 正确思路：把初始化流程封装在
public final void start()中，内部调用protected abstract void doInit() - 这样既保证子类必须提供定制逻辑，又防止外部跳过准备步骤直接调用抽象方法
接口 vs 抽象类中抽象方法的可见性差异
接口里的抽象方法没有“继承可见性”问题，因为它不涉及实现细节；抽象类则要考虑子类是否能实际重写并参与多态。
- 接口方法永远是
public abstract（即使不写修饰符），且不可降级访问权限 - 抽象类中
protected abstract是合法的，但子类重写时不能改成private或default—— 重写不能缩小访问范围 - 如果抽象类在模块 A，子类在模块 B，且用了模块化（如 Java 9+），还要确保
exports正确，否则protected方法也会因包不可见而无法重写
