答案是删掉"minimum-stability": "dev"、确保composer.lock已提交、禁用xdebug、运行composer why-not定位冲突，并使用--no-dev --prefer-dist --optimize-autoloader --classmap-authoritative四参数组合执行install。
composer install卡在“Resolving dependencies”怎么破
这不是网络慢，是 Composer 在本地暴力穷举所有版本组合。约束越宽（比如 "monolog/monolog": "^1.0 || ^2.0"）、minimum-stability 设为 dev、或 lock 文件缺失，都会让求解时间从秒级跳到分钟级。
- 删掉
composer.json里的"minimum-stability": "dev"—— 默认stable就够用，能砍掉 70%+ 的候选版本 - 确保
composer.lock已提交进 Git；没 lock 文件，install实际上会退化成update，触发全量解析 - 临时禁用 Xdebug：
php -d xdebug.mode=off /usr/bin/composer install，它会让解析慢 5–10 倍 - 运行
composer why-not vendor/package:version定位拖慢 solver 的具体包，比干等强得多
生产部署必须用的 install 参数组合
单靠 --optimize-autoloader 或 --no-dev 不够——前者不触发 classmap 扫描，后者不减少 solver 阶段内存占用。真正起效的是四参数联动：
-
--no-dev：跳过require-dev包安装，也防止测试类污染 autoload_classmap.php -
--prefer-dist：强制走 ZIP 包而非 Git clone，避开 SSH 认证、分支切换开销 -
--optimize-autoloader（或-o）：启用类映射生成，但仅当配合--classmap-authoritative才真正生效 -
--classmap-authoritative（或-a）：让 autoloader 彻底跳过file_exists()检查，查不到就报错，不兜底
完整命令：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative。漏掉任意一个，classmap 就可能为空、加载仍慢、或 solver 内存仍爆。
autoload_classmap.php 为什么还是空或加载慢
很多人跑完 composer dump-autoload -o 发现 vendor/composer/autoload_classmap.php 没数据，根本原因是：这个命令默认不扫描源码目录，只重写轻量级映射文件。
-
classmap只在composer install或composer update时自动生成（除非你显式配置了"classmap": ["src/"]） - 仅执行
dump-autoload -o= “优化一个空映射表”，实际没类路径数据 - 验证方法：打开
autoload_classmap.php，看数组是否为空或条目极少 - 开发中新增类后，
--classmap-authoritative会导致Class not found错误——不是 bug，是暴露了命名空间拼写错误（比如漏反斜杠）或路径未声明
CI/CD 中 APCu 缓存 classmap 为何不生效
--apcu-autoloader 看似高级，但有硬性前提：它只在 PHP-FPM 下有效，CLI 模式下完全不工作（apc.enable_cli=0 是默认值）。
- PHP-FPM 环境需确认
apc.enable_cli已关闭，且apc.shm_size足够（大型项目 classmap 数组常超 10MB） - APCu 缓存的是 classmap 数组本身，不是文件内容；若 classmap 更新但 APCu 未刷新，仍加载旧路径
- CI/CD 中建议搭配
opcache_reset()或 FPM reload，避免缓存 stale 数据 - 开发环境别用 —— 动态类加载会失效，改个类名就得手动清 APCu
最易被忽略的一点：权威模式（--classmap-authoritative）和 APCu 缓存必须同时启用才发挥最大价值；单独用任一个，性能提升都打折扣。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
