删 composer.lock 会导致 install 失败或不可控行为，新版 Composer 直接报错，旧版则导致依赖不一致；正确做法是用 update 重建 lock，而非 install。
删 composer.lock 会直接导致 install 失败或行为失控
新版 Composer（v2.5+）遇到缺失 composer.lock 时，composer install 命令根本不会执行，而是报错 Command "install" is not defined；旧版可能静默跳过，但实际装出的 vendor/ 极大概率不一致、不可复现。这不是“暂时没锁”，而是命令语义被破坏——install 的唯一职责就是按锁还原，没锁就无依据可依。
- CI/CD 流水线中若缺失 lock 文件，
composer install实际退化为不受控的update，每次构建结果都可能不同 - 团队成员本地删了 lock 又跑 install，其他人却保留原 lock，同一 commit 下
vendor/内容天然分裂 - 某些框架（如 CodeIgniter 4）依赖 lock 中记录的 autoloader 映射，缺失后即使类文件存在也会报
Class not found
删 lock 后别用 install，必须用 update 重建
删掉 composer.lock 后硬跑 composer install 是无效操作，正确路径只有一条：composer update。它会重新解析 composer.json 中所有约束（包括 require-dev），生成全新依赖树，并写入新的 composer.lock。
-
composer update是唯一受控重建 lock 的方式；install永远不参与版本决策 - 避免全局更新：用
composer update monolog/monolog --with-dependencies限定范围，防止意外带入冲突子依赖 - CI 环境应永远用
composer install，且必须确保composer.lock已随代码拉取到位；禁止在部署脚本里调用update
删 lock 的真实风险是放弃确定性契约
composer.lock 不是缓存，也不是临时文件，它是项目依赖状态的权威快照。删它等于主动交出版本控制权，让 Composer 自行决定装什么——而这个“决定”可能引入未经测试的补丁、不兼容的次要版本，甚至因 PHP 版本限制被迫降级到带已知漏洞的老包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 常见后果：
monolog/monolog从 2.10.2 升到 3.0.0（接口变更）、guzzlehttp/guzzle因依赖链变化降级回 7.2.0（触发 DNS 缓存 bug） - 安全扫描工具（如 phpstan-security）依赖 lock 文件比对历史基线，删 lock 后告警失效
- Git 提交记录里若出现
composer.lock被删又重建，基本意味着某次发布已埋下隐患，回溯困难
误删后最安全的恢复方式是 Git 回退
删了 composer.lock 后不该重建，而应从最近一次有效 commit 恢复：git checkout HEAD -- composer.lock。再删 vendor/，最后跑 composer install。这是唯一能保证依赖状态与代码历史严格对齐的做法。
- 手动编辑
composer.lock极其危险：改错一个version或sha256字段，下次install就会因 JSON 解析失败或校验不通过而中断 - 合并冲突后不要直接
install：lock 文件内容损坏，必须先git checkout --ours或--theirs拣选干净版本，再重装 - 如果真要重生成 lock（比如明确要升级全部依赖），也必须走
composer update --lock，而不是删文件+install
真正难处理的不是删 lock 这个动作，而是删完之后还误以为 “只要再跑一遍 install 就好了”。它背后牵扯的是整个依赖图的确定性、环境一致性、以及团队协作的隐性契约。
