--profile 是性能瓶颈定位探针而非分析工具，通过耗时跳变精准指出“哪里慢”，需配合 -v 查看具体包名和URL，结合镜像源、约束收敛等手段优化。
--profile 不是性能分析工具，而是性能瓶颈定位探针：它不告诉你“为什么慢”，但能精准指出“哪里慢”。
怎么看 composer install --profile 的输出
执行后终端会逐行打印带时间戳的操作日志，格式统一为 [内存/耗时] 操作描述。关键不是看总时间，而是观察“耗时跳变”——某一行比前一行多出几百毫秒甚至几秒，就是瓶颈所在。
-
Resolving dependencies through SAT耗时突增 → 依赖解析卡住，常见于composer.json中用了*、^1.0 || ^2.0这类宽泛约束，或存在隐式冲突 -
Downloading https://repo.packagist.org/...单次请求超 500ms → 网络问题，大概率是源站延迟或 DNS 慢，不是包本身大 -
Writing lock file或Generating autoload files耗时高 → 磁盘 I/O 慢（如 WSL、虚拟机）、autoload 配置未优化，或项目含大量小文件
为什么 --profile 必须搭配 -v 才有用
默认输出只显示阶段摘要，比如“Downloading 45 packages”，你根本不知道是哪个包在拖后腿。加 -v（即 composer update --profile -v）后，会暴露具体 URL 和包名，才能判断是不是某个私有包、GitHub 仓库或大体积 dist 包导致卡顿。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 没
-v：只看到[120.6MiB/28.74s] Resolving dependencies through SAT - 有
-v：能看到Resolving dependencies through SAT (28.74s) — trying package-a:1.2.0, then package-b:3.4.1... - 不重定向就直接刷屏：建议用
composer update --profile -v > profile.log 2>&1保存下来慢慢看
下载慢 ≠ 包大，90% 是源的问题
Downloading 阶段耗时长，几乎从不因为包体积大（Composer 默认走 dist，压缩包通常几 MB），而是反复连接 repo.packagist.org 或 GitHub API 失败/超时。国内环境尤其明显。
- 切镜像源是最有效解法：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 别信“本地缓存已满”：Composer 缓存机制正常，慢一定不是缓存导致的
- 验证是否生效：看
Downloading行的 URL 是否变成镜像地址（如https://mirrors.aliyun.com/composer/p2/...） - 如果用了私有仓库，记得同时配好
repos.packagist和对应私仓的http-basic认证，否则 fallback 到官方源会暗中重试，拖慢整体
依赖解析慢时，别急着升级 Composer
很多人以为换 Composer 2.x 就能解决 SAT 求解慢，其实效果有限。真正起作用的是约束收敛——求解器再快，也得算完所有组合可能。
- 检查
require-dev：开发依赖常引入重型工具（如phpunit/phpunit+ 全套断言库），它们也会参与解析，加--no-dev能立刻验证是否缓解 - 删掉模糊版本：
"monolog/monolog": "^2.0"比"monolog/monolog": "2.10.0"多试几十个候选版本 - 避免交叉约束：
"laravel/framework": "^10.0"和"spatie/laravel-backup": "^8.0"若未严格对齐生态兼容性，SAT 会陷入回溯深渊
真正容易被忽略的是：--profile 不报错、不警告、不建议，它只冷静列出数字。你得自己盯住那一行突然跳高的毫秒数——那才是问题真正的入口。其他所有优化，都该从那里开始。
