生产部署必须用 composer install --no-dev --optimize-autoloader，因为 dump-autoload -o 不重建 classmap，仅优化已有映射；而 install 命令才触发完整扫描并生成 autoload_classmap.php，配合 --no-dev 确保 classmap 仅含生产类且无干扰。

直接结论：生产部署必须用 composer install --no-dev --optimize-autoloader，不是 dump-autoload -o，也不是改 composer.json 里的 "optimize-autoloader": true。

为什么 composer dump-autoload -o 大概率没用

它只重写 autoload 文件，不重建 classmap —— 在 Composer 2.x 下，autoload_classmap.php 默认根本不会生成，除非你显式配置了 "classmap" 或用了 --classmap-authoritative。多数项目只靠 PSR-4，-o 对它无效，因为 PSR-4 的映射逻辑本身不依赖 classmap 文件。

• dump-autoload -o 不扫描 vendor 或 src 目录，只是“优化已有的映射”，而默认安装流程里这些映射压根没被 classmap 覆盖
• 运行后检查 vendor/composer/autoload_classmap.php：如果文件为空、不存在，或只有几行，说明没生效
• PHP 7.4+ + Composer 2.x 环境下，-o 反而可能拖慢冷启动——它强制加载一个几 MB 的全量数组，而实际请求只用到其中不到 5% 的类

composer install --optimize-autoloader 才是真动作

这个命令在安装依赖的同时，触发完整 classmap 生成流程：扫描所有 autoload.psrr-4 声明的路径（如 "App": "app/"），提取每个 .php 文件里的 class/interface/trait 声明，写入 autoload_classmap.php。这才是真正跳过运行时 file_exists() 和路径拼接的关键。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 必须搭配 --no-dev：否则 autoload-dev.psrr-4 也会被扫进 classmap，白增体积、干扰生产行为
• 不依赖 composer.json 里是否写了 "optimize-autoloader": true —— 那个配置只影响 dump-autoload 的默认行为，且容易被命令行参数覆盖
• CI/CD 脚本里应固定写成：composer install --no-dev --optimize-autoloader --prefer-dist

开了 --optimize-autoloader 却报 Class not found 怎么办

这不是参数错了，是 classmap 漏类了。预生成机制很死板，只认三件事：路径在 autoload.psrr-4 里声明了、文件名和命名空间严格匹配、文件里真有 class Xxx 声明。

• 检查命名空间末尾有没有反斜杠："App\": "app/" ✅，"App": "app/" ❌（会导致 AppHttpController 被拼成 app/Http/Controller 而非 app/Http/Controller/）
• 新增类后没重新 install/update？--optimize-autoloader 是一次性快照，改了代码必须重跑安装命令
• 用了 "files" 类型加载（比如全局函数文件）？这类不会进 classmap，但也不该报错——报错说明你误以为所有 autoload 都走 classmap
• 测试类混在主 autoload 里？确保 tests/ 只在 autoload-dev 块中，否则部署时会被扫进去又因 --no-dev 被剔除，导致 classmap 不一致

别忘了 PHP 层的配套动作

classmap 再快，没 opcache 也是白搭。vendor/autoload.php 和 autoload_classmap.php 都是 PHP 文件，每次请求都要解析；不启用 opcache，等于把磁盘 IO 换成了重复编译。

• 确认 opcache.enable=1 且 opcache.enable_cli=1（CLI 场景如 PHPUnit、部署脚本也需要）
• opcache.memory_consumption 至少设为 128，否则大项目的 autoload 文件可能被挤出缓存
• 禁用 opcache.validate_timestamps=1（开发环境除外），否则每次请求都 stat 文件，classmap 优势归零
• 首次部署后，用 curl 或 ab 多打几次健康接口，等 opcache “热起来”再测真实性能

真正卡点不在要不要加 -o，而在 classmap 是否覆盖了你实际用到的类、opcache 是否真的缓存住了 autoload 文件、以及 --no-dev 是否彻底隔离了开发路径。这三个条件缺一，优化就只是纸面数据。