必须执行composer dump-autoload -o，因其生成静态类名→路径映射表，跳过PSR-4运行时路径拼接与文件判断，显著降低IO开销；TP6+已弃用think optimize:autoload，仅Composer优化有效。
直接结论：优化核心是生成优化类映射 + 控制 autoload 触发范围，不是调换 psr-4 顺序。
为什么 dump-autoload -o 是必须的
ThinkPHP 6+ 启动时每 new 一个类，都要走 Composer 的 PSR-4 匹配逻辑：拆解命名空间、逐级比对目录、拼接路径、判断文件是否存在。这个过程在未优化时是纯运行时解析，开销明显。
加 -o 参数后，composer dump-autoload 会扫描所有 psr-4 和 classmap 声明的路径，提前生成一张「类名 → 文件绝对路径」的静态映射表（存于 vendor/composer/autoload_classmap.php）。后续类加载直接查表，跳过路径拼接和文件存在性判断。
- 必须在生产环境构建镜像时执行，不能只在本地跑一次
- 若项目含大量自定义类（如
app/library/下几十个子目录），不加-o会导致首屏加载延迟明显 - TP6 的
think optimize:autoload命令已废弃，它生成的是 TP 自己的映射，不替代 Composer 的-o
files 和 classmap 能提升性能吗
能，但适用场景不同：files 是无条件预加载，classmap 是精准查表，两者都绕过 PSR-4 的字符串解析流程。
立即学习“PHP免费学习笔记（深入）”；
例如你有 3 个关键工具类：Helper.php、ConfigLoader.php、Encryptor.php，它们不属任何命名空间，或命名空间不规范（如带下划线），用 psr-4 加载效率低且易出错。
- 把它们统一放进
app/common/functions.php，然后在composer.json的autoload.files中声明："app/common/functions.php" - 若要覆盖框架某模块（如重写
thinkcachedriverRedis），把新类放override/cache/driver/Redis.php，再用classmap扫描override/cache/目录 -
files里的代码会在每次请求一开始就执行，不能依赖尚未加载的类；classmap则按需加载，更安全
哪些 autoload 配置会拖慢启动
最常被忽略的是「过度声明」和「路径污染」——它们不会报错，但让 Composer 白扫一堆不存在的文件。
- 在
psr-4里写"app\": "app/"同时又写"app\library\": "app/library/"，后者实际已被前者覆盖，徒增扫描负担 - 把整个
vendor/或runtime/目录塞进classmap，Composer 会递归遍历所有子文件（包括 .git、.log 等） - 开发时临时加的
files没删干净，比如引用了本地调试工具类，上线后仍保留，每次请求都多 require 一个文件 - TP5 升级到 TP6 后没清理旧的
thinkLoader::addNamespace()调用，导致同一命名空间被注册两次
Docker 构建时 autoload 容易漏掉的关键点
容器里报 Class 'thinkApp' not found，90% 是 autoload 没生效，而不是类文件丢了。
- Dockerfile 中
COPY . /app必须在composer install --no-dev --optimize-autoloader之前，否则复制的是空vendor/ - 确保入口文件
public/index.php第一行就是require __DIR__.'/../vendor/autoload.php';，TP6 默认有，但有人为精简删掉了 - 镜像构建完成后，进容器执行
php -r "var_dump(class_exists('Composer\Autoload\ClassLoader'));"，返回bool(true)才算 autoload 基础就绪 - 别在
docker run启动命令里加composer install，这会让每次重启都重新生成 autoload，且无法利用缓存层
真正影响性能的从来不是「有没有 autoload」，而是「autoload 是否做了无谓工作」。删掉冗余配置、坚持 -o、避免在 files 里塞业务逻辑，比调换 psr-4 顺序实在得多。
