composer install 卡在 autoload 生成的主因是自动加载器生成耗时及重复解析依赖树，尤其类多、测试文件混入或 dev 依赖未清理时，autoload_classmap.php 膨胀致扫描写入变慢。
composer install 为什么卡在 autoload 生成？
生产部署时最常卡在 composer install，根源往往不是下载慢，而是自动加载器生成耗时 + 重复解析依赖树。尤其当项目含大量小类、测试文件混入 autoload 配置，或启用了未清理的 dev 依赖时，vendor/composer/autoload_classmap.php 可能膨胀到数 MB，扫描和写入都变慢。
- 加
--no-dev：跳过require-dev中所有包（如phpunit、larastan），省掉 30–60% 时间 - 显式加
--prefer-dist：强制用压缩包而非 Git 克隆（虽然默认已启用，但显式写上更稳妥） - 必须配
--optimize-autoloader（不是--optimize，后者在 Composer 2.0+ 已废弃） - 关键一步：
--classmap-authoritative—— 它才真正关掉 fallback 查找，否则-o效果打折扣
推荐组合：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
dump-autoload -o 为什么有时没用？
composer dump-autoload -o 确实能提速，但只在类映射可静态化时生效；加了却没效果，大概率是 PHP 进程没重载新 autoloader，或者 classmap 没覆盖运行时实际用到的类。
- CLI 下执行后立即测试没问题，Web 请求里类仍找不到 → 检查 OPcache 是否启用，运行
opcache_reset()或重启php-fpm - 改了 PSR-4 映射路径但类不生效 →
classmap是静态扫描结果，必须显式加--classmap-authoritative才会重扫全部源码 -
"autoload": {"classmap": ["src/"]}里误加了tests/或vendor/→ 导致 classmap 文件体积暴增、构建变慢 - 用了
"files": ["src/helpers.php"]却没加进 classmap → 这类全局函数文件不会被-o自动收录，得靠files显式加载才快
classmap-authoritative 能不能本地开发开？
不能。加了 "classmap-authoritative": true 后，Composer 会跳过所有 PSR-4/PSR-0 动态查找，只从 classmap 中加载类 —— 这能提速，但代价是：任何没被 classmap 覆盖的类（比如 Tinker 临时写的类、IDE 补全生成的桩、PHPUnit 的 Mock 类）直接报 Class not found。
- 适合场景：CI/CD 构建、Docker 镜像打包、线上部署——代码稳定、无运行时动态类生成
- 本地开发慎用：除非你明确知道哪些路径进了 classmap（可查
vendor/composer/autoload_classmap.php） - 一个隐蔽坑：
autoload-dev里的路径如果没被--no-dev过滤，也会进 classmap，上线后可能意外加载测试类引发冲突
要不要用 APCu 缓存 autoload？
要，但仅限支持 APCu 且启用了 apcu.enable_cli=1 的生产环境。它把 classmap 查找结果缓存在内存里，进一步减少 stat 调用，对高并发 CLI 命令或 Web 请求有明显收益。
- 启用命令：
composer dump-autoload --classmap-authoritative --apcu --apcu-autoloader - 注意：APCu 缓存需手动失效（如部署后调用
apcu_clear_cache('user')），否则旧 classmap 仍被命中 - CI 构建阶段不要加 APCu 参数，避免缓存污染或权限问题
- 若用 OPcache，确保
opcache.revalidate_freq=0且部署后调用opcache_reset()
classmap 不是银弹，它把“查找成本”转嫁成了“构建成本”和“灵活性损失”。上线前务必验证 classmap 是否完整覆盖所有运行时类，否则 Class not found 错误会掩盖真实路径或命名问题。
