Java访问修饰符中protected权限是“包内+子类（无论是否同包）”，访问时调用方必须是声明类的子类且代码在子类内部；default为包级可见；非静态内部类可访问外部类private成员，因编译器生成桥接方法。
Java 的访问修饰符直接决定类成员能否被其他类访问，不是“能不能写出来”，而是“编译器是否允许你这么用”。private、default（包级）、protected、public 四种修饰符中，protected 最容易误解——它既不是“子类专用”，也不是“包内通用”，而是“包内 + 子类（无论是否同包）”的组合权限。
为什么 protected 成员在不同包的非子类里访问会报错？
这是最常踩的坑：以为只要加了 protected 就能在任意地方通过子类间接访问父类成员。实际上，Java 规定：访问 protected 成员时，调用方必须是该成员声明类的子类，且访问行为必须发生在子类内部（或其子类内部）。外部类即使持有子类引用，也不能借道访问父类的 protected 字段或方法。
- 错误示例：
SubClass obj = new SubClass(); obj.protectedField = 1;—— 合法，因为obj是SubClass实例，且赋值发生在SubClass内部或其子类中 - 错误示例：
OtherClass（不同包、非子类）中写subObj.protectedMethod()—— 编译失败，哪怕subObj是子类实例也不行 - 关键点：
protected控制的是“谁可以写这行访问代码”，而不是“谁的对象能被访问”
default（无修饰符）的实际作用域是包，不是“当前类”
很多人误以为不写修饰符就只是“本类可用”，其实 default 成员对整个包可见，包括包内所有类（无论是否继承关系）。这点和 private 有本质区别。
- 场景：工具类
StringUtils.java中定义static final String DELIMITER = ",";（无修饰符），同一包下所有类都能直接用StringUtils.DELIMITER - 风险：如果项目按功能分包但没严格隔离，
default成员可能意外暴露给不该访问的类 - 对比：
private static final才真正限制为仅本类可见；若想对外提供但限制范围，应显式用public+ 接口抽象
内部类如何影响访问权限判断？
非静态内部类（inner class）天然拥有对外部类所有成员的访问权，包括 private。这不是绕过访问控制，而是编译器在生成字节码时自动插入了桥接方法（bridge methods）。
立即学习“Java免费学习笔记（深入）”；
class Outer {
private int secret = 42;
class Inner {
void reveal() {
System.out.println(secret); // ✅ 合法，编译器生成了 access$000(Outer) 方法
}
}
}
- 注意：这种访问只适用于“同一个 .java 文件中定义的内部类”；来自其他文件的独立类（哪怕名字叫
Outer$Inner）无法访问Outer.private - 静态内部类（
static class）不享有此特权，它和普通类一样受常规访问规则约束 - 反射仍可突破这些限制，但那是运行时行为，编译期访问检查照常执行
真正难处理的不是记清四种修饰符的定义，而是理解 Java 访问控制始终以“源码中访问语句所在的类 + 声明位置 + 继承关系”三者共同判定。一个 protected 方法在子类中可调用，在子类的内部类中也可调用，但一旦被提取到独立的工具方法里，哪怕参数类型是子类，也立刻失效。
