composer install --profile可精准定位瓶颈：Resolving dependencies耗时高说明约束逻辑问题，Downloading卡住指向镜像或缓存失效，Generating autoload files超1s提示类扫描爆炸；-vvv才暴露真实卡点，如SAT求解失败、cURL错误或扩展缺失。
用 --profile 看清哪一步真慢
直接跑 composer install --profile，别猜。输出里每行都带耗时（秒）和内存（MB），关键看三项：
-
Resolving dependencies耗时高 → 问题在 composer.json 的约束逻辑，不是网络 -
Downloading package xxx卡住或单个包耗时超 5s → 镜像源或缓存失效 -
Generating autoload files超 1s → 新包可能含大量类、扫描逻辑或 PSR-4 映射爆炸
注意：--profile 只反映安装过程，不反映运行时慢；如果 require 'vendor/autoload.php' 慢，得另查。
加 -vvv 才能看到真实卡点
-v 和 -vv 基本没用，它们只显示“正在下载”，不暴露底层失败原因。-vvv 才会打印：
- cURL 原始请求头和未解压响应体（比如看到
zlib_decode(): data error就是代理损坏了压缩流） - SAT 求解器每一步排除了哪个版本（停在
Resolving dependencies through SAT后无下文？说明约束不可满足） - 插件堆栈、缺失扩展提示（如
ext-xml没装但config.platform写了）
常见陷阱：config.verbose=false 会静默屏蔽 -vvv；COMPOSER_DISABLE_XDEBUG=1 必须加，否则堆栈被截断；终端滚动太快就重定向：composer install -vvv 2>&1 | tee debug.log。
别信缓存，先清再验
composer clear-cache 不等于清干净。它默认只清 ~/.composer/cache 下的 repo/files/http，但权限错或磁盘满会导致清理失败：
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 先确认路径：
composer config --global cache-dir - 手动进该目录，检查
downloads/和files/是否为空 - 清完再跑
composer install -v，日志里出现Downloading而非Using cache才算生效
更彻底的做法是加 --no-cache：它禁用本次所有缓存查找，强制重新下载每个包，配合 --prefer-dist 和 --no-dev 能跳过 git clone 和开发依赖解析，大幅缩短时间。
内存不够时，php -d 必须放最前
composer install 卡在 Resolving dependencies，90% 是内存溢出，但调参顺序错了就白忙：
- 错误写法：
composer install -d memory_limit=-1（参数被当 Composer 子命令）或COMPOSER_MEMORY_LIMIT=-1 composer install（PHP 进程早被默认 128M 卡死） - 正确写法：
php -d memory_limit=-1 composer install（Linux/macOS）或php -d "memory_limit=-1" composer install（PowerShell） - 单位必须大写：
2G有效，2g被 PHP 忽略
--optimize-autoloader 和 --no-dev 是真降内存的组合——前者跳过 PSR-4 动态扫描，后者避免解析 phpunit、laravel/pint 等重型开发依赖。
真正卡住时，往往不是某一行报错，而是日志停在某个阶段不动、或反复重试同一动作。这时候别换镜像、别重装 Composer，先让 -vvv --profile 把执行流打出来，再按阶段逐个验证——多数瓶颈藏在你没注意到的配置覆盖、缓存残留或 PHP CLI 环境差异里。
