Java访问修饰符权限控制本质是编译期契约，javac在编译时严格检查合法性，JVM运行时不校验修饰符；反射绕过属API特例，非运行时权限机制。
Java 访问修饰符的权限控制，表面看是“能不能访问”，实际分两层：编译期由 javac 静态检查是否合法，运行期由 JVM 动态执行时才真正起作用——但**运行期并不重新校验访问权限**。换句话说，权限检查只发生在编译期；一旦通过编译，字节码里就不再有“private 不能调用”这类运行时拦截机制。
编译期检查：决定代码能否通过，不依赖对象真实状态
javac 在编译时严格依据引用类型（声明类型）和作用域规则判断访问合法性：
- 调用
private方法或字段？只看当前类是否定义它，不关心运行时对象是不是子类实例 - 访问
protected成员？检查调用者是否在同包内，或是否为该类的子类（静态继承关系），不看运行时对象是否真的属于那个子类 - 接口中
default方法被实现类重写？编译器要求重写方法必须是public（不能降级为protected或private），这个约束在编译阶段就强制执行 - 如果代码试图跨包访问
default（包级私有）成员，javac 直接报错，不会生成 .class 文件
运行期不检查访问修饰符，但行为受其间接影响
JVM 执行字节码时，不会再次验证 private、protected 等修饰符。但它会忠实执行编译后生成的指令——而这些指令本身，就是编译期权限检查的结果：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 编译器拒绝生成对
private字段的直接访问字节码，所以运行时根本不存在“偷偷访问”的可能 - 反射可以绕过编译期检查（如
field.setAccessible(true)），但这不是 JVM 放宽权限，而是反射 API 主动打破封装，属于特例，并非运行期权限模型的一部分 - 字段访问永远是静态绑定：即使
Parent p = new Child();，访问p.field拿到的仍是Parent类中定义的字段（哪怕Child有同名字段），因为字段不参与重写，编译期就锁死了符号引用
特殊场景：接口方法权限的编译期硬约束
接口里的访问修饰符规则更体现编译期主导性：
立即学习“Java免费学习笔记（深入）”；
- 接口中所有普通方法默认是
public abstract，你写private void f()—— Java 8 会直接编译失败（Java 9+ 才允许private辅助方法，且仅限于static或default方法内部调用） -
default方法虽带关键字，但编译后访问标志仍是ACC_PUBLIC，实现类重写时若擅自加private，javac 立即报错：“attempting to assign weaker access privileges” - 这些限制都发生在
.java → .class转换过程中，与 JVM 启动与否无关
为什么没有运行期权限校验？设计上就是如此
Java 的访问控制本质是**编译期契约**，目的是帮助开发者在编码阶段发现结构错误，而不是运行时做安全沙箱：
- 加
private不是为了防 JVM，而是告诉编译器“这里不该被外部碰”，从而避免误用和耦合 - 如果真需要运行时权限控制（比如多租户系统），应使用安全管理器（SecurityManager，已弃用）或应用层策略，而非依赖
private/protected - 这也解释了为什么反编译后的字节码能看到所有字段和方法——JVM 只认符号引用和指令，不认“private”这个词
