composer卡在“resolving dependencies”是sat求解器暴力回溯版本组合所致，非文件死锁或网络问题；需用--dry-run -v定位卡点，再通过composer why-not或depends --tree分析闭环依赖并重构约束。
Composer 本身不会发生“多任务文件死锁”——它不是并发程序，没有文件锁竞争逻辑。你看到的卡住、无响应、高 CPU 或零输出，99% 是依赖求解器陷入 SAT 回溯风暴，或本地环境阻塞（如网络、权限、PHP 配置），不是文件系统级死锁。
为什么 composer update 卡在 “Resolving dependencies” 不动？
这不是死锁，是 Composer 的依赖求解器在暴力尝试所有版本组合。当约束太紧（比如多个包对同一底层库提出互斥版本要求），它可能回溯数万次后才放弃，表现为“卡住”。典型现象包括：
- CPU 拉满但终端无日志输出（
composer update --dry-run -v可确认） - 持续 60 秒以上无进展，且
composer.lock未更新 - Windows 下 cmd 窗口假死，实际进程仍在后台跑
实操建议：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 立刻中断并运行
composer update --dry-run -v，观察末尾是否出现重复路径（如vendor/a → vendor/b → vendor/a），这是递归依赖闭环的铁证 - 别等它自己退出——SAT 求解器没有超时机制，会一直算到内存耗尽
- 用
ps aux | grep composer（Linux/macOS）或任务管理器（Windows）确认是否真卡住，还是单纯慢
“Permission denied” 或 “failed to open stream” 是真文件锁吗？
不是文件锁，是权限或路径问题。Composer 在写 vendor/ 或 cache 目录时失败，报错里带 Permission denied 或 file could not be downloaded，本质是：
- 用
sudo composer install导致 vendor/ 下部分文件属主为 root，后续普通用户操作被拒 - Windows 上杀毒软件或 OneDrive 正在扫描 vendor/ 目录，临时阻塞写入
- ca-bundle 路径失效（尤其 WSL 或 Docker 中），导致 HTTPS 请求失败
实操建议：
- 修复权限：
sudo chown -R $USER:$USER vendor/ composer.lock（Linux/macOS） - 临时关闭实时防护（如 Windows Defender 的“实时扫描”）再重试
- 不推荐长期用
--no-secure-http，应运行composer config -g cafile /path/to/cacert.pem修复证书链
composer.lock 被破坏或缺失时怎么手动恢复？
lock 文件损坏（如 JSON 格式错误）或丢失，不能靠“重装”恢复一致性。必须从现存状态重建契约：
- 若
vendor/和composer.lock都存在：先composer install验证能否还原；失败则删composer.lock，再composer update --lock生成新 lock（注意：这会改变版本） - 若只有
vendor/（composer.lock丢了）：运行composer show --installed获取已装包列表，人工补composer.json的require字段，再composer update --lock - 若
vendor/和composer.lock全丢：只能靠 Git 历史找回composer.json，然后composer install（此时退化为update行为）
关键点：永远不要手动编辑 composer.lock —— 它是二进制安全哈希和拓扑结构的序列化结果，手改必破。
CI/CD 中反复失败，是不是镜像源导致的？
国内镜像（如阿里云、腾讯云）只加速下载，不参与依赖解析。如果你的 CI 流水线在 composer install 阶段失败，错误信息里出现 Root composer.json requires ... but it is not satisfied，说明不是镜像问题，而是：
-
composer.lock和composer.json不匹配（比如改了 json 但没提交新 lock） - CI 环境 PHP 版本低于
composer.lock中platform.php声明的最低版本 - CI 使用了旧版 Composer（v2.1 以下），对某些约束解析行为不同
实操建议：
- 在 CI 脚本开头加
composer --version和php -v日志 - 强制使用一致的 Composer 版本：
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - 用
composer install --no-interaction --prefer-dist --optimize-autoloader，避免交互和 dev 包干扰
真正容易被忽略的是：Composer 的“卡住”永远发生在解析阶段（CPU 高），而“失败”永远发生在安装阶段（报错明确）。盯住错误关键词，比猜锁机制快十倍。
