默认不解决Class not found，因仅刷新PSR-4映射而不扫描类文件、不重建autoload_classmap.php；必须加-o强制扫描并生成类映射，必要时补-a重扫classmap路径，部署后还需清OPCache。
类找不到，八成不是代码写错了，而是 Composer 的“地图”没更新——composer dump-autoload 是最直接的修复动作，但**不加参数基本等于白跑**。
为什么 dump-autoload 默认不解决 Class not found？
默认执行 composer dump-autoload 只刷新 PSR-4/PSR-0 映射文件（如 autoload_psr4.php），但不会扫描实际类文件、不重建 autoload_classmap.php，更不会清理旧路径残留。尤其当你：
- 刚移动或重命名了类文件
- 新增了未被 PSR-4 覆盖的独立
.php文件（比如放在src/Helpers/里但没声明命名空间） - 改过
composer.json里的autoload.classmap字段但没触发重扫
这时候映射里还存着旧路径，new MyClass() 必然失败。
必须加 -o 才算真正重建类映射
-o（即 --optimize）是生产环境和排查问题时最关键的参数。它强制 Composer：
- 递归扫描所有
autoload配置的目录（包括psr-4、classmap、files） - 生成/覆盖
vendor/composer/autoload_classmap.php，把每个类名精确映射到物理路径 - 跳过运行时文件查找，直接查表加载，性能更高也更可靠
示例命令：
composer dump-autoload -o
注意：-o 会忽略 autoload.files 中的全局函数文件（如 src/functions.php），如果项目依赖这类文件，得额外确认是否仍被 vendor/autoload.php 正确引入。
遇到 classmap 不生效？补上 -a 参数
如果你在 composer.json 里显式配置了 "classmap": ["src/", "lib/"]，但 -o 后 autoload_classmap.php 里还是没有新类，说明扫描没覆盖非标准结构的文件（比如无命名空间的 Utils.php）。这时必须加 --classmap-authoritative（简写 -a）：
-
-a强制 Composer 把classmap当作唯一可信来源，不再 fallback 到 PSR-4 推断 - 它会重新遍历
classmap指定路径下**所有**.php文件，不管有没有命名空间或类声明 - 常和
-o一起用：composer dump-autoload -o -a
⚠️ 注意：加了 -a 后，如果某个类不在 classmap 里，就彻底加载不到——所以确保路径配置准确，末尾斜杠不能少（"src/" ✅ vs "src" ❌）。
部署后还报错？别忘了清 OPCache
即使 autoload_classmap.php 时间戳已更新、内容正确，PHP 还可能从 OPCache 里读取旧的类路径缓存。典型表现是：
- 本地
dump-autoload -o后立刻好使，服务器上不行 -
var_dump(class_exists('MyClass'))返回false，但文件明明在映射里
解决方法只有两个：
- 执行
php -r "opcache_reset();"（需opcache.enable=1且opcache.revalidate_freq=0） - 重启 PHP-FPM 进程（
sudo systemctl restart php8.1-fpm）或 Web 服务器（如 Apache）
这个步骤经常被跳过，但它和 dump-autoload 是配套动作——地图更新了，但导航软件还在用缓存数据，当然找不到路。
