Composer自动加载慢的根源在于classmap未覆盖关键类，需手动将稳定模块加入composer.json的"classmap"字段，并关闭Error初始化器、优化runtime路径及权限。
自动加载慢，不是类多，是映射没走对路——composer dump-autoload -o 生成了 autoload_classmap.php，但你的类根本没进这张表里。
为什么 composer dump-autoload -o 后还是慢
加了 -o 不等于启用 classmap 模式。Composer 默认用 PSR-4 动态拼路径 + is_file() 判断，每次 new 类都要遍历目录；而 classmap 是扁平 key-value 映射，查表即得路径，跳过所有 I/O。
- 检查
vendor/composer/autoload_classmap.php：目标类（比如app\order\model\Order）是否已出现在数组中？键是完整类名，值是绝对路径 -
app/目录默认不在 classmap 里——它得手动加进composer.json的"classmap"字段 - 别把整个
app/塞进去：它常变动，每次composer dump-autoload都要全量扫描，开发体验反而更差 - 只对稳定模块加 classmap：如
library/Utils/、vendor/mycorp/sdk/src/
ThinkPHP 的 Loader::addNamespace() 能提速吗
不能。它是运行时注册的字符串匹配逻辑，每次请求都调用函数 + 多次 is_file()，比 PSR-4 还慢一层。
- 典型误用：在
app/provider.php里反复调用Loader::addNamespace('MyLib', __DIR__ . '/mylib') - 它不生成静态映射，也不影响 Composer 的 autoload 流程，纯属徒增开销
- 真要加速，就把
MyLib写进composer.json的"psr-4"或"classmap"，交给 Composer 统一管 - 这个方法只适合极小范围兜底或调试，比如临时加载一个没进 Composer 的老脚本
生产环境必须关掉 think\initializer\Error
这个初始化器默认启用，会在首次报错时反向扫描栈、尝试加载未定义类——本质是「出错补救」，但会触发大量文件 I/O 和正则匹配，放大慢加载问题。
立即学习“PHP免费学习笔记（深入）”；
- 关闭方式：在
config/app.php中设'error_handler' => false - 或更彻底地，在应用初始化阶段移除：
\think\initializer\Error::class => null - 它不影响错误日志记录，只是去掉非必要环节；若你依赖框架外的
__autoload补充逻辑，才需谨慎评估 - 搭配
APP_DEBUG=false和清空缓存（php think clear）一起做，否则旧的调试态缓存仍可能生效
runtime 目录位置和权限也会拖慢自动加载
不是磁盘慢，是 PHP 进程反复调用 is_dir()、mkdir()、写锁文件时被卡住——尤其在 Docker 或 NFS 挂载下，延迟会被放大数倍。
- 把
runtime改到/tmp/thinkphp-runtime这类本地 tmpfs 路径，避开网络文件系统抖动 - 显式配置
'runtime_path' => '/tmp/thinkphp-runtime/'，别依赖默认相对路径 - 确保目录权限为
755，且属主与 PHP 进程一致（如www-data），否则每次写缓存都要触发 ACL 检查 - 顺手关掉不用的日志类型：
'log' => ['type' => 'null']，避免每请求都写日志文件
真正卡住自动加载的，往往不是类本身，而是那些你以为“无关紧要”的配置项、目录权限、错误处理补救逻辑——它们叠加起来，让 classmap 的优势完全失效。
