执行 composer dump-autoload 后类仍找不到，主因是 php 进程未重载 autoloader（如 opcache 未清除、php-fpm 未重启）、classmap 未重新扫描或 autoload 配置与实际路径不匹配。
composer dump-autoload 为什么有时没用
执行 composer dump-autoload 后类还是找不到，大概率是 autoloader 没重新加载，或者你改的是 PSR-4 映射但没清缓存。Composer 的自动加载器生成后会缓存到 vendor/autoload.php 和 vendor/composer/autoload_*.php，但 PHP 进程（尤其是 CLI 或常驻进程如 Swoole、PHP-FPM）可能仍用着旧的 opcode 缓存或已加载的类表。
- CLI 下跑完
dump-autoload立即测试，没问题；但 Web 请求里类未更新 → 检查 OPcache 是否启用，运行opcache_reset()或重启 PHP-FPM - 用了
"classmap": ["src/"]但新增类不生效 → classmap 是静态扫描结果，必须显式加--optimize或--classmap-authoritative才会重扫 - 开发中频繁改命名空间路径 → 别依赖
dump-autoload救急，直接检查composer.json里的autoload/autoload-dev是否匹配实际目录结构
classmap-authoritative 能不能随便开
加了 "classmap-authoritative": true 后，Composer 会跳过所有 PSR-4/PSR-0 动态查找，只从 classmap 中加载类 —— 这能提速，但代价是：任何没被 classmap 覆盖的类（比如测试时临时写的文件、插件动态注册的类）直接报 Class not found。
- 适合部署环境：代码稳定、无运行时动态类生成、已确保
composer dump-autoload --classmap-authoritative扫全了所有源码 - CI/CD 构建时建议加
--no-dev+--classmap-authoritative，避免 autoload 逻辑在生产环境兜底失效 - 本地开发慎用：IDE 自动补全、Tinker、PHPUnit 临时类都可能崩，除非你明确知道哪些路径进了 classmap（看
vendor/composer/autoload_classmap.php）
autoload-dev 里的路径会影响生产性能吗
不会。Composer 在安装/更新时默认只处理 autoload，autoload-dev 只在 composer install --dev 或 composer dump-autoload --dev 时写入 autoload 文件。但有一个隐蔽坑：如果你在生产环境执行了 composer install 却忘了加 --no-dev，那 autoload-dev 里的 PSR-4 映射也会被载入，导致 autoload 文件变大、OPcache 占用更高、甚至意外加载测试类引发冲突。
- 线上部署务必用
composer install --no-dev --optimize-autoloader -
autoload-dev里别放和autoload重叠的路径，否则dump-autoload可能生成重复映射，autoload 文件体积翻倍 - 某些包（如 PHPUnit 框架）会在
autoload-dev里注册全局函数（functions.php），这些函数即使没调用也会被 PHP 解析 —— 生产环境多加载几百行无用代码，不是零成本
vendor/autoload.php 加载慢，是不是该拆包
单个 vendor/autoload.php 大于 2MB、require 耗时超 5ms（用 microtime(true) 测），说明 autoload 文件臃肿，常见于大量小包、或用了 files 类型自动加载（每个 files 都是 require_once）。这不是“该不该拆包”的问题，而是 Composer 设计上就不鼓励 runtime 拆 —— 真正该做的是收缩入口、隔离非核心依赖。
- 确认是否真慢：用
php -d 'opcache.enable=0' -r "echo microtime(true); require 'vendor/autoload.php'; echo microtime(true);"测纯加载时间 - 删掉没用的
"files"：比如某些 SDK 把 helper 函数全塞进 autoload-files，其实只在 CLI 命令里用 → 改成按需 require - 大项目可考虑分层 autoload：核心服务用独立
composer.json+install --no-dev，Web 层只 require 核心 autoload，避免把队列、支付等模块的 autoload 全拉进来
autoload 优化的边界很清晰：它解决的是「类发现」开销，不是业务逻辑瓶颈。一旦你开始怀疑 autoload 拖慢接口，先确认是不是数据库查询、HTTP 调用或模板渲染在前面卡住了 —— 那些地方省下的毫秒，比压榨 autoload 更实在。
