--optimize-with-classmap 在 Composer 2+ 中已被彻底移除，因其不加速自动加载、反拖慢 dump-autoload 且增大 classmap 文件；替代方案为 --classmap-authoritative（生产环境）或 --apcu（开发环境）。
启用 optimize-with-classmap 不会加速自动加载，反而会让 composer dump-autoload 变慢、生成更大的 vendor/composer/autoload_classmap.php，且现代 PHP 项目中基本没用。
为什么 optimize-with-classmap 在 Composer 2+ 中已弃用
Composer 2.0 起默认启用类图优化逻辑（基于 classmap 的静态分析），但不再依赖手动开启的 --optimize-with-classmap 标志。该标志实际已被移除 —— 运行 composer dump-autoload --optimize-with-classmap 会报错：Unrecognized option "--optimize-with-classmap"。
- Composer 1.x 末期已标记为废弃，2.x 彻底删除
- 真正生效的是
--classmap-authoritative或--apcu等替代方案 - 旧文档或脚本里残留该参数，会导致 CI 失败或本地命令报错
--classmap-authoritative 才是当前等效替代
它让 Composer 完全信任 classmap，跳过文件系统扫描，从而提升自动加载性能。但它要求所有类必须能被 classmap 覆盖（即不能有动态 require、不能依赖未声明的文件）。
- 启用方式：
composer dump-autoload --classmap-authoritative - 适用场景：闭源部署、Docker 构建后镜像、无运行时动态加载的 CLI/HTTP 应用
- 风险点：如果项目中有
require __DIR__ . '/helpers/' . $name . '.php'类型逻辑，会直接Class not found - 验证是否生效：检查
vendor/composer/autoload_static.php中$classMap是否非空，且$classMapAuthoritative = true
什么时候该用 --apcu 而不是 classmap
APCu 缓存的是已解析的类名 → 文件路径映射，不依赖提前扫描，适合开发环境频繁改文件、又想避免重复 stat 的场景。
- 启用方式：
composer dump-autoload --apcu - 前提：PHP 启用了
apcu扩展，且apc.enable_cli=1（CLI 下生效） - 注意：APCu 缓存有生命周期，
apc.ttl默认 0（永不过期），但重启 Web 服务器或 CLI 进程后需重新 warmup - 和
--classmap-authoritative互斥：两者不能同时使用
classmap 优化本质是空间换时间，但代价是构建变慢、部署包体积增大、灵活性下降。现在更推荐按环境选策略：CI/生产用 --classmap-authoritative，开发用 --apcu，而 --optimize-with-classmap 这个名字，早该从脚本和记忆里删掉了。
