排查ClassNotFoundException需先确认模块是否声明依赖、导出包且可读；变量缺失则要区分是传参遗漏还是作用域/类型导致渲染为空，二者根源与解法完全不同。
排查模块化环境下的 ClassNotFoundException，核心不是“找不着 Jar”，而是确认“类是否被当前模块声明依赖、是否导出、是否可读”。变量缺失则需区分是模板引擎传参遗漏，还是作用域/类型导致渲染为空——二者常被混为一谈，但根源与解法完全不同。
查 ClassNotFoundException：先看模块声明，再看类加载路径
在 JPMS（Java Platform Module System）或 OSGi 等模块化环境中，ClassNotFoundException 很少因物理缺失引起，更多是模块可见性断裂：
- 检查目标类所在模块的
module-info.java是否用exports显式导出了该包（如exports com.example.domain;） - 确认当前模块是否用
requires声明了依赖（如requires example.domain;），且未加transitive时，间接依赖不会自动传递 - 运行时用
java --list-modules确认模块已加载；用jcmd <pid> VM.native_memory summary配合jstack查类加载器是否为ModuleLayer实例 - 若使用
Class.forName("X")，确保调用方模块对目标类模块有opens（反射需要）或已启用--add-opens参数
定位模板变量缺失：盯住编译缓存行号和实际传入快照
变量缺失不是 Java 层的 ClassNotFoundException，而是视图层参数未抵达模板上下文。关键动作是让框架暴露原始映射关系：
- 启用模板调试模式（如 ThinkPHP 的
'template' => true），确保runtime/template/xxx.php缓存文件中保留/* line 42 */注释，直接反查 HTML 模板第 42 行 - 在控制器末尾加
trace($this->view->getAssign(), 'VIEW_ASSIGN')，查看调试面板中实际传入的键值对，注意闭包、资源句柄等不可序列化类型会显示为Closure或Resource id #x - 若变量存在但渲染为空，检查是否为
null、空数组或0—— 模板引擎默认对 falsy 值静默输出，需改用{:print_r($data,1)}强制展开
交叉验证：用 JVM 级工具确认类是否真被加载
当怀疑是模块隔离导致类不可见，跳过 IDE 依赖图，直击 JVM 加载行为：
- 启动时加
-verbose:class，过滤目标类：java -verbose:class -jar app.jar 2>&1 | grep "YourClass"。若无输出，说明根本未尝试加载；若有输出但报ClassNotFoundException，说明加载失败发生在模块链接阶段 - 程序运行后，用
jcmd <pid> VM.class_hierarchy（JDK 17+）查看类加载器层级，确认目标类是否由ModuleClassLoader加载，而非系统类加载器 - 对 Maven 项目，执行
mvn dependency:tree -Dincludes=group:artifact，确认该依赖出现在compile或runtime范围，而非test或provided
避免混淆：ClassNotFoundException 和变量缺失本质不同
ClassNotFoundException 是 JVM 在字节码执行期找不到类定义，属于类加载失败；而模板变量缺失是业务逻辑未将数据塞入视图上下文，属于数据流中断。前者看模块声明与类路径，后者看控制器 assign() 调用与模板注释行号。两者日志位置也不同：前者抛在 Java 堆栈里（如 MyBatis 解析 SysConfig 别名失败），后者只在 PHP/FTL 渲染阶段报 Undefined variable 或占位符原样输出。
