必须删 lock + 清缓存 + --no-cache 才能真正重解析：composer install 仅还原 lock 文件，不清 lock 就不会重新计算依赖；clear-cache 只清磁盘缓存，--no-cache 才禁用全部缓存查找，确保走真实 HTTP 请求。
缓存清理后 install 还秒完成？检查是否真清干净了
执行 composer clear-cache 后，composer install 仍“瞬间完成”，说明 Composer 仍在复用某些残留缓存或本地状态。这不是 bug，而是它可能跳过了网络请求，直接用了 vendor/composer/installed.json 或 composer.lock 中的已知版本信息。
必须确认三件事：
-
composer config --global cache-dir输出的路径下，files/和repo/子目录确实为空（ls -la $(composer config --global cache-dir)/files应无输出） -
vendor/目录已被彻底删除（仅删vendor/composer/不够） -
composer.lock文件存在且未被修改——它会强制锁定旧版本，哪怕缓存全空也不会触发重解析
真正重新解析依赖：删 lock + 强制 no-cache
composer.lock 是解析结果的快照，不是缓存。不清掉它，composer install 永远只按锁文件还原，不重新计算依赖树。
正确流程是：
-
rm -rf vendor composer.lock（Linux/macOS）或rmdir /s vendor & del composer.lock（Windows） composer clear-cachecomposer install --no-cache --prefer-dist --optimize-autoloader
其中 --no-cache 是关键：它禁用所有本地 ZIP 包查找，也跳过 repo/ 元数据缓存读取，确保每一步都走真实 HTTP 请求和 SAT 解析。
为什么 update 比 install 更容易卡在 SAT 阶段？
composer install 只还原 composer.lock 记录的精确版本，基本不触发约束求解；而 composer update 会主动尝试升级，启动 SAT 求解器遍历所有满足 require、conflict、PHP 版本、扩展等条件的组合。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
若你刚清完缓存却想跑 update，极可能卡在 Resolving dependencies through SAT —— 这说明约束不可满足，不是慢，是逻辑死锁。
此时应：
- 先用
composer update -vvv --profile确认停在哪一行 - 若卡在 SAT，立刻停掉，改用
composer why-not vendor/package:version定位阻断链 - 不要反复重试，SAT 回溯是指数级耗时，越等越久
CI/CD 或 Docker 构建中避免缓存干扰
在持续集成环境里，composer install 偶尔成功、偶尔失败，大概率是构建节点残留了旧缓存或 composer.lock 含有源地址硬编码（如私有镜像 URL 已失效）。
安全做法是：
- 每次构建前加
RUN rm -rf vendor composer.lock && composer clear-cache - 确保
composer.json中repositories配置正确：repo.packagist键名不能多写s，type必须为composer，URL 结尾必须带/ - 用
composer install --no-cache --no-dev --optimize-autoloader -v，日志里出现Downloading https://...才算真正重拉
最易被忽略的是 composer.lock 的源头问题：它可能是在另一台机器上生成的，镜像配置不同，导致本地根本无法解析出包路径——这种错误不会报明确提示，只会静默卡住或 fallback 到 packagist.org 而超时。
