VarHandle 本身不参与访问控制，真正决定能否访问私有字段的是 MethodHandles.Lookup 实例的权限等级；MethodHandles.lookup() 限本类，publicLookup() 仅限 public 字段，privateLookupIn() 是唯一合法跨类访问私有字段的方式，且需满足模块读取、类加载器一致等三重校验。
VarHandle 本身不参与访问控制决策，真正决定能否访问私有字段的是 MethodHandles.Lookup 实例的权限等级。它不是“开关”，而是一把带刻度的钥匙——能开哪扇门，取决于这把钥匙是怎么锻造出来的。
Lookup 实例的三种常见来源及其权限边界
不同方式创建的 Lookup 实例，能触及的字段范围差异很大：
- MethodHandles.lookup()：仅限本类内部使用。可直接 findVarHandle 访问本类的 private 字段，但无法跨类访问其他类的私有成员，哪怕目标类是子类或同包
- MethodHandles.publicLookup()：权限最窄。只能访问 public 字段，且目标类必须对调用方模块“可读”（reads）；private、protected、package-private 字段一律不可见
- MethodHandles.privateLookupIn(Target.class, lookup)：唯一合法跨类访问私有字段的方式。前提是当前 lookup 所在类已被授权（如通过 --add-opens 显式开放模块），否则抛 IllegalAccessException，而非 NoSuchFieldException
三重校验缺一不可
即使你拿到了一个看似可用的 Lookup 实例，访问私有字段前仍需同时满足：
- 语言可见性：private 字段只认“声明它的那个类”作为合法调用者；不能靠反射 setAccessible() 绕过
- 模块读取权限：若目标类在命名模块中（如 java.base），你的模块必须已声明 reads 它；否则即使同包、同类加载器也会失败
- 类加载器一致性：Lookup 实例所属类与目标类通常需由同一类加载器加载；跨加载器时，JVM 还会校验 ProtectionDomain 是否允许该访问
拿到 VarHandle 后，权限检查就结束了
一旦成功获取 VarHandle（比如通过 findVarHandle），后续所有 get/set/CAS 等操作都不再触发访问控制检查——这是性能关键设计。但要注意：
- 基本类型字段（如
int value）对应 varType 必须是int.class，不是Integer.class - 数组字段（如
String[] data）的 varType 必须写成String[].class，不能用Object[].class - 调用
invokeExact()时，参数类型必须与字段声明类型严格一致；invoke()的自动转换在私有字段句柄上不生效
为什么不能用 publicLookup().in(YourClass.class)？
这种写法看似“切换到目标类”，实则无效。publicLookup() 创建的实例天生不具备私有访问能力，in() 只是改变查找上下文，并不提升权限等级。它仍受限于 publicLookup 的原始约束——只看 public 成员。试图用它访问 private 字段会直接抛出 NoSuchFieldException，连权限校验环节都进不去。
