IllegalAccessError是JVM运行时错误，非编译期异常，因类加载器隔离或访问权限违规（如跨包访问package-private成员）导致；Maven中provided等scope会改变类加载层级，破坏“同包可见”前提，从而触发该错误。
IllegalAccessError 通常不是编译期报错，而是在运行时抛出的、与类加载和访问控制强相关的错误。它表示某个类试图访问另一个类的成员（字段或方法），但该成员的可见性不满足 JVM 的访问规则——比如访问了 package-private（即默认包级访问）的成员，而调用方类不在同一包中，且未通过合法方式（如 public 接口、反射授权等）获得访问权。在 Maven 项目中，**依赖范围（scope）设置不当会间接导致 IllegalAccessError**，根本原因在于：它改变了类的实际加载来源和类加载器层级，进而破坏了“同包可见”的前提。
为什么 scope 影响包级访问？
Maven 的 scope 决定了依赖在什么阶段参与构建、是否打包进最终产物、由哪个类加载器加载。关键点在于：
-
compile：参与编译、测试、运行；JAR 打入lib/，由应用类加载器（AppClassLoader）加载；所有类在同一个类路径下，包级访问正常生效。 -
provided：仅参与编译和测试；不打入最终包，运行时由容器（如 Tomcat）或 JDK 自带提供；此时你的类和容器提供的类可能由不同类加载器加载（如 BootstrapClassLoader 加载 servlet-api，AppClassLoader 加载你的代码），即使包名相同，JVM 也视为“不同包”——因为类加载器不同，package-private访问被拒绝。 -
runtime或test：不参与编译，但可能在运行时存在；若误用于本该编译期可见的工具类，会导致编译通过、运行时报NoClassDefFoundError或IllegalAccessError。
典型触发场景：跨模块包内调用 + provided 依赖
假设你有一个工具类 com.example.util.ConfigHelper，其中定义了一个 static final String DEFAULT_ENV = "dev";（包级访问，无修饰符）。另一个模块 A 通过 Maven 引入该工具模块，且 scope 设为 provided。模块 B 在运行时加载了模块 A 的类，又试图直接访问 ConfigHelper.DEFAULT_ENV —— 此时若模块 A 和工具模块实际由不同类加载器加载（常见于 Web 容器环境），JVM 就会判定它们“不属于同一个运行时包”，从而抛出 IllegalAccessError。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
如何快速定位和修复？
遇到 IllegalAccessError 时，不要只盯着访问语句本身，重点检查依赖链和加载上下文：
- 用
mvn dependency:tree -Dverbose查看目标类所属依赖是否被标记为provided或runtime，尤其关注是否与当前模块不在同一 classloader 层级。 - 在 IDEA 中右键点击报错类 → “Go to Declaration”，确认跳转到的源码是否来自
provided依赖（IDEA 通常标为 “Maven: xxx (provided)”）。 - 检查运行环境：是本地
java -jar运行？还是部署到 Tomcat/Jetty？后者更易因provided导致类加载器隔离。 - 修复原则：对需要在运行时被其他模块直接访问的类及其成员，确保其所在依赖使用
compilescope；若必须用provided（如 Servlet API），则避免直接访问其包级成员，改用 public 方法或标准接口。
比 ClassNotFoundException 更隐蔽的风险
不同于 ClassNotFoundException 明确提示“找不到类”，IllegalAccessError 往往出现在看似合法的调用之后，堆栈里看不到明显缺失依赖。它暴露的是 JVM 类加载模型的底层约束：**包访问权限不仅取决于源码中的修饰符，还取决于类是否由同一个类加载器加载**。Maven scope 设置一旦打破这个前提，编译无误、测试通过，上线后却突然失败——这正是它容易被忽略又难以调试的原因。
