Composer install卡在Resolving dependencies是本地SAT求解器暴力穷举版本组合所致，非网络问题；树深+松约束（如"php": ">=7.4"）引发指数级回溯，应通过composer depends --tree找枢纽包、composer why-not定位冲突，并用replace/conflict剪枝、删dev分支、精简autoload与lock文件优化。
Composer install卡在Resolving dependencies不是网络问题
这是本地 PHP 进程在跑 SAT 求解器，暴力穷举所有可能的版本组合。树越深、约束越松（比如"php": ">=7.4"或"monolog/monolog": "^1.0 || ^2.0"），搜索空间就呈指数爆炸。日志停在这一行几十秒，composer install -vvv没后续 HTTP 请求，基本就能断定是解析风暴，不是镜像源或磁盘慢。
依赖树“深”本身不慢，但“枢纽包+松约束”会触发回溯爆炸
真正拖慢的不是目录嵌套层数，而是某个包被多个顶层依赖间接拉入（比如symfony/console被 6 个不同组件同时 require），再叠加宽泛版本约束——求解器必须为每个分支尝试所有兼容路径。用composer depends --tree --max-depth=2 vendor/package-name找这类枢纽节点，比composer show --tree更准；再配合composer why-not php:8.2，能直接暴露阻断升级的具体路径和版本冲突点。
不删包、不降级，靠replace和conflict提前剪枝
与其等求解器算完再失败，不如主动收口搜索空间：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"replace": {"psr/log": "3.0.0"}—— 告诉 Composer 这个包只存在一个确定版本，其他所有候选直接跳过 -
"conflict": {"symfony/console": "=10.0"}—— 明确标记已知死路，避免浪费时间在必然失败的组合上 - 删掉
"minimum-stability": "dev"—— dev 分支候选集太大，稳定版能砍掉约 80% 解析时间 - 避免
"psr/log": "*"或"some/lib": "dev-main"—— 这类写法让求解器失去剪枝依据
autoload 和 lock 文件膨胀是隐性杀手
大项目里vendor/autoload.php加载慢，常因autoload_classmap.php超 10MB；composer.lock达 12MB，则解析 JSON 和构建图本身就会吃 CPU。解决方式很具体：
- 运行
composer dump-autoload --classmap-authoritative --apcu，跳过文件存在性检查，用 APCu 缓存类位置 - 在
autoload-dev里加"exclude-from-classmap": ["tests/", "Tests/"]，防止测试类污染生产 autoload - 清理 lock 文件：删掉长期不用的
require-dev包（如旧版phpstan/phpstan），archive.exclude字段也能减重
这些操作不改变功能，但会让composer install从分钟级回到几秒——前提是别在 WSL2 挂载卷或 Docker volume 上直接跑 install，vendor 目录 I/O 也是硬伤。
