-xbootclasspath用于替换jvm启动时加载核心类（如java.lang.*）的路径，直接修改bootstrap classloader的类搜索路径；它会完全覆盖默认路径，需严格匹配jvm版本，jdk9+应改用模块化参数。
Java -Xbootclasspath 是干啥的？
它直接替换 JVM 启动时用来加载 java.lang.*、java.util.* 等核心类的路径，绕过默认的 rt.jar（或 JDK 9+ 的 modules）。不是给你的应用代码用的，是给 JVM 自己“换内脏”的开关。
常见错误现象：java.lang.NoSuchMethodError 或 LinkageError 出现在 String、ClassLoader 这种基础类上；或者加了某个 agent 后启动失败，报 java.lang.BootstrapMethodError —— 很可能就是 bootclasspath 搞乱了系统类的版本一致性。
-
-Xbootclasspath会完全覆盖默认路径，慎用；更安全的是-Xbootclasspath/a:（append）或-Xbootclasspath/p:（prepend） - JDK 9+ 中，
rt.jar已不存在，-Xbootclasspath对大多数模块无效；改用--add-modules或--patch-module更合适 - 如果你只是想让自己的类被“当成系统类”加载（比如某些字节码增强场景），大概率走错了路 —— 应该用
Instrumentation.appendToBootstrapClassLoaderSearch()，而不是硬塞进 bootclasspath
怎么验证当前 bootclasspath 实际生效了？
别猜，用 System.getProperty("sun.boot.class.path") —— 这个值在 JDK 8 及以前有效；JDK 9+ 返回 null，因为模块系统接管了。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- JDK 8：启动时加
-XshowSettings:properties，搜sun.boot.class.path行 - JDK 11+：用
jcmd <pid> VM.system_properties</pid>看，但注意该值已无意义；真正要看的是java -XshowSettings:vm -version输出里的java.class.path和模块配置 - 写个最小测试类，故意调用一个你“以为”被 bootclasspath 替换掉的类的方法，再用
javap -verbose查它的Constant pool，确认实际加载来源
为什么 -Xbootclasspath/p: 容易导致 UnsupportedClassVersionError？
因为你在 prepend 路径里塞了一个低版本编译的 java.util.ArrayList，而 JVM 自身是 JDK 17 启动的 —— 类文件版本号对不上，直接炸。
根本原因：bootclasspath 上的类和 JVM 运行时版本必须严格匹配。JVM 不做兼容性检查，只认版本号。
- 所有放在
-Xbootclasspath/p:下的 JAR，必须用和当前 JVM **完全一致的 JDK 版本**重新编译 - 不要试图用 JDK 11 的 bootclasspath 加载 JDK 8 编译的工具类 —— 即使源码一样，class 文件格式也不同
- 调试时可临时用
javap -v MyClass | grep "major version"确认 class 文件版本
替代方案：什么时候该放弃 bootclasspath？
绝大多数日常开发、测试、甚至部分字节码插桩需求，都不需要碰它。真要改底层行为，优先走标准扩展机制。
- 想扩展
java.*类？用--patch-module java.base=/path/to/patch（JDK 9+） - 想让自定义类加载器提前看到某些类？把它们放进
ClassLoader.getParent()（即 Platform ClassLoader）能加载的路径，而不是塞进 Bootstrap - Agent 场景下需修改系统类？用
Instrumentation.redefineClasses()或transform()钩子，比动 bootclasspath 安全得多
bootclasspath 是 JVM 启动时就锁死的路径，一旦设错，连 main 方法都进不去。它不像普通 classpath 那样可以后期补救 —— 错了就得重启 JVM，而且很难定位到底是哪一行 class 文件坏了事。
