必须验证三步：一看vendor/composer/autoload_classmap.php存在且非空；二用php -d opcache.enable=0 -r "require 'vendor/autoload.php';"测真实加载；三查classmap是否覆盖所有类，漏则上线报class not found。
CI/CD里跑完composer install --optimize-autoloader怎么确认它真生效了
光加参数不等于优化落地。很多CI流水线写了--optimize-autoloader，但没验证 classmap 是否生成、是否被加载、有没有漏类——结果上线后冷启动变慢，或某天突然Class not found。
验证分三步：看文件、测加载、查覆盖。
-
vendor/composer/autoload_classmap.php文件必须存在且非空（至少几百行），否则--optimize-autoloader根本没触发 - 运行
php -r "require 'vendor/autoload.php'; echo 'OK';"只是基础通路检查；更关键的是加-d opcache.enable=0禁用OPcache，排除缓存干扰，再测真实加载路径 - 用
composer show --installed --no-dev | wc -l对比历史安装包数量，若骤减，说明--no-dev生效了，但也要同步检查vendor/composer/autoload_psr4.php里是否还残留tests/或dev命名空间——那是--no-dev没起作用的信号
为什么composer dump-autoload -o在CI里是错操作
CI中不该手动执行dump-autoload。它不读composer.lock，也不处理依赖下载，只改本地 autoload 文件——而CI每次都是干净环境，vendor/从零重建。
真正该做的是让composer install自己完成优化流程：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer install --no-dev --optimize-autoloader --classmap-authoritative是完整组合，它会在安装同时生成 classmap 并强制只走 classmap 查找 - 如果项目用了
"optimize-autoloader": true写在composer.json里，这个配置对install无效，只影响dump-autoload命令，CI里等于白写 - 执行完后检查
vendor/composer/autoload_static.php里$classMap数组长度，和autoload_classmap.php行数基本一致才算成功落地
如何发现 classmap 漏掉关键类
漏扫最常发生在两类地方：未声明的目录（比如src/Support/没写进autoload.ps4）、动态生成类（如Laravel的__construct()里class_exists()触发的临时类）。
验证不能只靠“不报错”，得主动探测：
- 用
find src/ -name "*.php" | xargs grep "class " | cut -d' ' -f2 | sort -u提取所有类名，再逐个php -r "class_exists('XXX') && print 'OK\n';"测试——适合核心模块抽查 - 在CI末尾加轻量运行时检查：
php -d auto_prepend_file=vendor/autoload.php -r "echo count(get_declared_classes());"，数值明显低于本地开发环境，大概率有类没进 classmap -
--classmap-authoritative开启后，任何未进 classmap 的类都会直接Fatal error，所以CI里一旦开了这个，就必须确保composer install输出里有Generating optimized autoload files这一行，且无Warning: Class XXX was not found
Serverless或短生命周期环境要额外盯什么
函数计算、FaaS这类环境冷启动敏感，classmap 文件大小和首次 require 开销会直接影响响应延迟。
除了常规验证，还得看两点：
- 检查
vendor/composer/autoload_classmap.php体积：超过 500KB 就要警惕——不是越大越好，冗余路径（如tests/、examples/）会拖慢解析；用--no-dev和--classmap-authoritative能有效压缩 - 避免
autoload.files大量引入全局 PHP 文件：它们会在每次请求都执行，无法被 OPcache 全量优化；CI里可用grep -r "autoload\.files" vendor/快速扫描第三方包是否有滥用 - PHP 8.1+ 环境下，确认
opcache.preload没误加载vendor/autoload.php——它和 classmap 机制冲突，会导致预加载失败静默跳过
composer install用的composer.lock版本变了，classmap 内容就可能不同，但CI脚本里如果没强制校验composer.lock时间戳或哈希值，就可能把旧 classmap 缓存复用到新依赖上。
