执行 composer dump-autoload 未生效是因为未加 -o 参数，仅重写 autoload_files.php 和类名映射数组，不生成 classmap；加 -o 才扫描所有目录并硬编码类名到大数组，跳过文件系统遍历。
composer dump-autoload 为什么没生效？
执行 composer dump-autoload 后启动还是慢，大概率是因为没加 -o（optimize）参数。默认模式只重写 autoload_files.php 和类名到文件路径的映射数组，不生成真正的“类映射表”（classmap）。只有加了 -o，Composer 才会扫描所有 PSR-0/PSR-4 目录 + files 配置项里的文件，把每个类名硬编码进一个大数组里，跳过文件系统遍历。
-
composer dump-autoload -o：生成 classmap，适用于稳定依赖，但会忽略动态注册的类（比如运行时 require 的文件） -
composer dump-autoload --classmap-authoritative：配合-o使用，告诉 Autoloader “classmap 就是全部”，不再 fallback 到 PSR-4 文件查找 —— 这步能再省一次 stat() 系统调用 - 如果项目用了
files类型自动加载（比如全局 helper 函数），它们也会被包含进优化后的 classmap，但函数名不会被索引 —— 只有类、接口、trait 被映射
什么时候不该用 classmap 优化？
开发阶段频繁增删类文件时，composer dump-autoload -o 会成为负担：每次改完都要手动重跑，否则新类找不到。更麻烦的是，某些 IDE 或热重载工具（如 Symfony’s var-dumper + ServerCommand）依赖实时文件发现，classmap 会绕过这个机制，导致断点不触发或 var_dump 输出异常。
- 本地开发环境建议用
composer dump-autoload（无参数）保持灵活性 - Docker 构建阶段或 CI/CD 打包时再加
-o --classmap-authoritative - 若项目含大量未命名空间的 PHP 文件（比如传统 WordPress 插件风格），classmap 会把它们全塞进映射表，但这些文件不含
class声明 —— 白占内存，还可能引发Class not found报错（因为 Composer 试图 autoload 它们）
autoload-dev 里的类会被优化进主 classmap 吗？
不会。autoload-dev 下的 PSR-4 映射（比如 "Tests\": "tests/"）默认不参与 dump-autoload -o，除非显式加上 --dev 参数。但生产环境通常不需要测试类，硬塞进去反而增大映射表体积、拖慢加载。
-
composer dump-autoload -o --dev：仅在需要运行测试的场景下使用（如 PHPUnit 在容器内执行） - 生产部署脚本里务必去掉
--dev，避免把tests/目录下的类也编译进 classmap - 检查最终生成的
vendor/composer/autoload_classmap.php，确认里面没有Tests\或Example\这类开发专用命名空间
classmap 大小和性能的真实影响
一个 5000 行的 autoload_classmap.php 文件，PHP 解析开销几乎可以忽略（微秒级），真正卡顿来自两个地方：一是 classmap 数组太大导致 OPCache 内存占用飙升，二是某些旧版 PHP（
- 用
composer show --platform确认是否启用了 OPCache；没开的话，classmap 优化收益极小 - 执行
composer dump-autoload -o --no-dev && php -r "echo memory_get_peak_usage() / 1024 / 1024 . " MB\n";"对比优化前后内存峰值 - 如果 classmap 文件超过 2MB，检查是否有 vendor 包把整个
docs/或resources/目录错误声明进了 autoload（常见于老旧 Laravel 包）
--classmap-authoritative 和 OPCache 配合。单独加 classmap 没用，必须让 autoloader 彻底信任这张表，才真正跳过文件系统探测。 
