直接改 composer.lock 会导致校验失败、安装报错或 vendor 不一致，因它含精确哈希与结构化依赖快照，手动修改会破坏 content-hash、子依赖树或 json 格式，引发 invalid argument supplied for foreach() 等错误。
直接改 composer.lock 会出什么问题
手动编辑 composer.lock 是最危险的“捷径”。它不是配置文件，而是 Composer 自动计算出的依赖快照，包含包名、精确版本、哈希值、依赖树结构等几十个字段。哪怕只改错一个逗号或缩进，composer install 就会报 Your lock file is not up to date 或直接拒绝执行。
更隐蔽的风险是：你改了某个包的版本号，但没同步更新它的子依赖列表、哈希值、或者 content-hash —— 这会导致安装时校验失败，或者装出不一致的 vendor 目录。线上环境一旦出现这种“看似装上了、运行时报 Class not found”，排查成本极高。
常见错误现象：
- 改完
composer.lock后composer install报错Invalid argument supplied for foreach()（实际是 JSON 解析失败） - 本地能跑，CI 构建失败，因为 CI 用的是严格校验模式，而你的手工修改绕过了依赖求解器逻辑
- Git 提交后别人
composer install，结果装出和你完全不同的子依赖版本
composer update --lock 和删 lock 文件的区别
composer update --lock 是唯一安全的“重写 lock 文件”方式：它不碰 vendor/，不查远程仓库，只根据当前 composer.json 和已安装包的状态，重新生成合法、结构完整、哈希匹配的 composer.lock。
而删掉 composer.lock 再跑 composer install，等于放弃锁定——Composer 会从头解析整个依赖树，可能把 monolog/monolog 从 2.9.1 升到 2.10.0，把 symfony/polyfill-php81 从 v1.28.0 换成 v1.29.0，甚至引入一个你从未测试过的 psr/cache v3.x —— 这些都不是你想要的“同步”，而是失控。
适用场景：
- 你改了
composer.json（比如加了个新包、删了个 dev 依赖），但不想重装 vendor，只想让 lock 文件跟上 - 团队里有人误删了 lock 文件，你手头有干净的 vendor，想快速恢复 lock
- 升级 PHP 版本后提示平台不兼容，先用
composer update --lock --ignore-platform-reqs生成新 lock，再逐步修正环境
为什么 composer prohibits 能比 why-not 更快定位锁死点
composer why-not 回答的是“为什么我装不上这个版本”，输出是一条或多条依赖路径；而 composer prohibits 直接告诉你“谁在明确禁止它”，答案往往就一行，且精准指向冲突源头。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
例如执行 composer prohibits guzzlehttp/guzzle:7.8.0，返回：
myapp/core v2.3.1 requires guzzlehttp/guzzle ^6.5
这就比 why-not 输出里嵌套三层的 “A → B → C → requires guzzle ^6.5” 更直给。尤其当你面对 Laravel、Symfony 这类大框架生态时，prohibits 能跳过中间包装包，直击真正卡住版本的那个 require 声明。
注意点：
- 必须指定完整版本号，比如
guzzlehttp/guzzle:7.8.0，不能只写:7.8 - 如果返回空，说明没有包显式禁止，问题可能出在平台约束（PHP 版本、扩展）或
conflict字段 - 搭配
--no-dev使用，可排除开发依赖干扰，聚焦主干冲突
锁死问题真正难处理的地方
最难的不是技术操作，而是判断“该不该动”。比如 monolog/monolog 被锁在 2.9.1，你想升到 3.0.0，但 laravel/framework 的 composer.json 明确写了 "monolog/monolog": "^2.0" —— 这时候强行升级，Laravel 内部调用的 Monolog\Logger::addRecord() 可能因签名变更而报错。
真正要花时间的，是确认上下游是否 ready：
- 查目标包的 CHANGELOG，看 major 版本是否有 BC break
- 看依赖它的主包（如 Laravel）是否已发布兼容版本，或 GitHub issues 里有没有人踩过同样坑
- 检查自己代码里有没有直接用了被废弃的方法，比如
Logger::getHandlers()在 monolog 3 里已移除
这时候，composer update monolog/monolog --dry-run 看改动范围，比任何命令都管用。锁死本身不是 bug，是 Composer 在替你守住兼容性边界。
