Composer自动加载失败时需执行composer dump-autoload -o，确认psr-4映射配置正确、路径与命名空间一致，并检查vendor/composer/autoload_psr4.php是否更新。
自动加载失败时，先看 composer dump-autoload -o 是否执行过
ThinkPHP 6+ 完全依赖 Composer 的 PSR-4 自动加载机制，框架自身不再维护类映射表。如果你新增了类但报 Class not found，大概率是 Composer 的 autoload 配置没生效或未刷新。
常见错误现象：本地开发能跑，部署到服务器就报错；或者改了命名空间、移动了文件后突然找不到类。
- 确认
composer.json中"psr-4"配置是否覆盖你的目录，例如："psr-4": { "app\": "app/", "extend\": "extend/" } - 修改命名空间或目录结构后，必须运行
composer dump-autoload -o（-o表示优化，生成 classmap 加速加载） - 线上环境若禁用
exec()，无法自动触发 autoload 重建，需在本地生成好vendor/autoload.php和vendor/composer/autoload_classmap.php后再上传
命名空间与路径不一致？用 composer show --path 快速验证
ThinkPHP 不校验命名空间和物理路径是否“看起来像”，它只信任 composer.json 里写的映射关系。你写 namespace appservicePay;，但把文件放在 app/common/Pay.php，只要 composer.json 没配 "app\common\"，就一定加载失败。
调试方法：运行 composer show extend --path（把 extend 换成你的命名空间前缀），它会直接输出该前缀映射到哪个目录。
立即学习“PHP免费学习笔记（深入）”；
- 如果返回空或报错，说明这个命名空间根本没注册进 autoload
- 如果返回路径不对（比如显示
/path/to/app但你实际放到了extend/），就是composer.json配错了 - 注意 Windows 路径分隔符不影响匹配，Composer 内部统一转为
/处理
think build 生成的类不会被自动加载？检查是否漏了 --module
ThinkPHP 的 think build 命令默认只生成控制器、模型等骨架，并不会自动往 composer.json 里追加 PSR-4 映射 —— 尤其是你用 think build service 创建了一个 appserviceWechat 类，但 app 前缀已存在，它不会帮你建 appservice 子目录映射。
真正起作用的是 think build --module=api 这类带模块参数的命令，它会尝试在 composer.json 中添加类似 "app\api\": "app/api/" 的配置项（取决于你模板里的定义）。
- 手动补映射更可靠：编辑
composer.json，在"psr-4"下增加一行，如"app\service\": "app/service/" - 补完记得立刻
composer dump-autoload -o，否则 build 出来的类永远“看不见” - 避免用
appcommon这类非标准子命名空间——除非你在composer.json显式声明，否则 ThinkPHP 不会自动识别
调试时别只盯 vendor/autoload.php，重点看 vendor/composer/autoload_psr4.php
Composer 加载类时，最终读取的是 autoload_psr4.php 这个 PHP 数组文件。它由 dump-autoload 生成，是真实生效的映射表。很多问题不是代码写错了，而是这个文件没更新，或内容有残留。
打开它，搜索你的命名空间前缀（比如 app\service\），确认：
- 键名是否严格匹配（末尾
\不能少，大小写敏感） - 对应值是否为绝对路径，且该路径下确实存在
.php文件 - 有没有重复定义（比如旧版映射没删干净，导致新路径被覆盖）
如果发现映射存在但路径指向错误目录，基本可以断定是 composer.json 配置有歧义（比如两个前缀都匹配到同一目录），这时需要删掉冗余项再重生成。
最隐蔽的问题：某些 IDE 或构建工具会在 vendor/composer/ 下缓存旧的 autoload 文件，手动删掉整个 vendor/composer/autoload_*.php 再 dump-autoload 更稳妥。
