先确认autoload_classmap.php是否包含该类：-o不生成classmap，需加-a强制扫描；--classmap-authoritative模式下若classmap无该类则直接失败；dev类须显式加--dev；OPCache未清也会导致类找不到。
composer dump-autoload -o 后类找不到，先看 classmap 是否真包含该类
加 -o 参数后，Composer 默认只优化 PSR-4 映射（写入 autoload_static.php），**不会自动生成或更新 autoload_classmap.php**——除非你已在 composer.json 的 "autoload": {"classmap": [...]} 中显式声明了扫描路径。否则，-o 对 classmap 毫无影响，而你误以为“优化 = 全量扫描”。
- 运行
composer dump-autoload -o -a强制重扫所有 classmap 路径（-a是关键） - 检查
vendor/composer/autoload_classmap.php，搜索你的完整类名（如'App\Services\UserService'），确认是否存在对应路径 - 若类在
src/下但未列在classmap配置里，-o完全不会让它进 classmap，PSR-4 仍会 fallback 查找——此时大小写、路径拼接、$baseDir偏移全可能出错
生产环境用 --classmap-authoritative 却报空类，检查 $baseDir 计算是否错位
--classmap-authoritative 模式下，Composer **彻底禁用 PSR-4 动态查找**，只信任 classmap 里的条目。一旦 classmap 里没这个类，就直接返回 false，不兜底。问题常出在构建流程中：$baseDir 被算成 /var/www/html/vendor/../..，但实际代码部署在 /app，导致 classmap 里存的路径是错的物理地址（比如 /var/www/html/src/Services/UserService.php），文件根本不存在。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在目标环境执行
php -r "var_dump(require 'vendor/composer/autoload_classmap.php');"，看类名映射的路径是否真实可访问 - 用
ls -l对照 classmap 中的路径，确认文件存在且权限正常 - CI/CD 中避免 “拷贝 src/ 到容器再运行 composer install”；应先
composer install --no-dev --optimize-autoloader --classmap-authoritative，再把整个vendor/和src/一起打包
autoload-dev 里的类（如测试、Factory）在 dump-autoload 后仍不可用
默认 composer dump-autoload **完全忽略 autoload-dev 配置**。Laravel 的 Database\Factories、Tests\Feature 或服务提供者中的 register() 方法引用的 dev 类，如果没加 --dev，就不会被扫描进任何映射文件。
- 新增测试类后必须运行
composer dump-autoload --dev - 若同时要优化，用
composer dump-autoload -o --dev；-o本身不隐含--dev - Laravel 项目中，
php artisan config:clear或php artisan optimize:clear不能替代这一步——框架缓存的是配置和路由，不是自动加载规则
OPCache 缓存了旧 autoload 文件，PHP 根本没读新生成的映射
部署后执行了 composer dump-autoload -o --classmap-authoritative，autoload_classmap.php 时间戳最新、内容正确，但 class_exists('App\Services\UserService') 仍返回 false——大概率是 OPCache 把旧的 opcode 缓存住了，PHP 解析时跳过了文件系统读取，直接用了过期的类路径信息。
- 在 PHP-FPM 环境下，执行
sudo systemctl reload php*-fpm或sudo service php*-fpm reload - 若用 OPcache API，运行
php -r "opcache_reset();"（需opcache.enable_cli=1） - CI/CD 流程中，
composer install后必须加清理步骤，不能只信文件生成成功
$baseDir 的计算、--classmap-authoritative 的零容错、OPCache 的静默缓存——三者叠加，最容易在上线那一刻同时爆发。 
