classmap生效需同时满足三条件：路径写入composer.json的"classmap"字段、执行composer dump-autoload -o、目标类文件在扫描时真实存在；缺一不可，否则autoload_classmap.php无对应条目，仍走PSR-4动态加载。
类库映射（classmap）不是“开了就快”，而是必须满足三个条件才真正生效：路径进 composer.json 的 "classmap" 字段、执行了 composer dump-autoload -o、且目标类文件在生成时确实被扫描到。漏掉任意一环，autoload_classmap.php 里就不会有对应条目，自动加载依然走 PSR-4 动态拼路径。
确认 classmap 是否真被生成和使用
别只看命令有没有报错，得进文件里查实锤。打开 vendor/composer/autoload_classmap.php，搜索你关心的类名（比如 app\controller\Index），如果没出现在数组键里，说明它根本没进 classmap。
- 常见假成功：只运行了
composer dump-autoload（没加-o），生成的是autoload_static.php，不是 classmap - 常见路径陷阱：把
"app/"写成"app"或"./app/"，Composer 不识别，直接跳过该目录 - 注意大小写：Linux 服务器上，
App/Controller/Index.php和命名空间app\controller\Index不匹配，classmap 会漏掉这个类
哪些目录适合加进 classmap，哪些坚决不能加
classmap 是静态快照，适合稳定、低频变更的代码；对开发中频繁增删改的目录，反而拖慢日常流程。
- 推荐加：自封装的工具库（如
"library/Utils/"）、第三方 SDK（如"vendor/mycorp/sdk/src/"）、ThinkPHP 扩展中的核心服务类 - 不建议加：
"app/"整体 —— 每次改一个控制器都要重跑composer dump-autoload -o，开发体验断崖下跌 - 严禁加：
"tests/"或"examples/"这类 autoload-dev 下的路径，它们会被扫进 classmap，徒增体积还污染生产映射
TP 自带的 php think optimize:autoload 有用吗？
这个命令生成的是 runtime/classmap.php，和 Composer 的 classmap 完全无关。它只是 ThinkPHP Loader 在运行时做的一层额外缓存，性能提升微乎其微，甚至可能因每次请求都读文件+反序列化而更慢。
立即学习“PHP免费学习笔记（深入）”；
- 它不改变 Composer 加载逻辑，
autoload_classmap.php没变，底层还是慢 - 该文件不会自动更新 —— 新增类后不手动再跑一次，新类永远进不了 runtime 映射
- 线上部署时若忘记同步
runtime/classmap.php，还会导致类找不到
为什么关掉 think\initializer\Error 能提速？
这个初始化器在 TP6+ 默认启用，作用是：出错时从异常栈反向找未加载的类，再触发一次自动加载。听起来像兜底，实际是性能黑洞。
- 它会在每次
Fatal error或Class not found后，遍历整个autoload_psr4.php做正则匹配 + 文件is_file()判断 - 尤其在开发阶段配合 Xdebug 断点，错误频发，这部分 I/O 开销会被放大数倍
- 关法很简单：在
config/app.php里加'error_handler' => false，不影响日志记录，只砍掉这层无意义补救
classmap 生效的关键不在“加了多少”，而在“加得准不准”——只固化真正高频、稳定、路径确定的类；其余部分留给 PSR-4 是合理分工，不是妥协。最容易被忽略的是：每次改完 composer.json，必须重新 dump-autoload -o，且要验证生成文件内容，而不是只信终端那句 “Generated optimized autoload files”。
