composer.lock中真正决定安装行为的字段是packages和packages-dev顶层字段，以及其中每个包的version、source.reference、dist.sha256、require（嵌套）；content-hash仅用于校验composer.json是否变更，不参与安装逻辑。
composer.lock 里哪些字段真正决定安装行为
它不是版本列表，而是一份可执行快照。composer install 只读 packages 和 packages-dev 两个顶层字段，其余全是辅助校验信息。
关键字段就这几个：
-
version：必须是完整语义版本（如"2.9.1"），不是"2.9"或"^2.0"—— 后者只存在于composer.json中，install完全无视 -
source.reference：Git commit hash（如"a1b2c3d4e5f67890"），决定源码检出点，不是 tag 或 branch 名 -
dist.sha256：ZIP 包校验值，下载后不匹配就重下，哪怕本地缓存有同名文件 -
require（嵌套在每个包下）：记录该包自己的依赖项，保证整个依赖树被完整锁定 -
content-hash：由composer.json全文（含空格、换行、字段顺序）生成的哈希，仅用于检测 json 是否被修改，不参与安装逻辑
为什么删了 composer.lock 后 composer install 会失败或装错
不是“装错”，是根本没走 install 流程 —— 新版 Composer（v2.5+）直接报 Command "install" is not defined；旧版可能静默 fallback 到 update 行为，但 vendor/ 内容必然不可控。
常见误操作及后果：
- CI 脚本漏传
composer.lock→ 每次构建拉取不同小版本，比如psr/http-message从1.0.1升到2.0.0，触发接口不兼容 - 本地误删后跑
composer install→ 实际执行的是隐式update，可能引入已知 bug 的版本（如guzzlehttp/guzzle7.2.0 的 DNS 缓存问题） - 手动编辑
composer.lock→ JSON 格式稍有偏差（多一个逗号、少一个空格）就会导致JSON decode error，后续autoload失败
如何安全回溯到某个历史版本的依赖状态
别重建，要恢复。composer.lock 是快照，不是日志，重建等于重抽依赖签，风险极高。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
正确回溯步骤：
- 查 Git 历史：
git log -n 5 --oneline -- composer.lock，找到对应上线或稳定版本的 commit - 恢复文件：
git checkout <commit-hash> -- composer.lock - 删干净 vendor：
rm -rf vendor/（不能跳过，否则残留包会干扰） - 执行还原：
composer install—— 如果报Your lock file does not contain a compatible set of packages，说明当前composer.json已和该 lock 不匹配，需先确认是否应同步 json 再继续
注意：composer update --lock 不是回溯命令，它只重写 lock 文件，不改变已安装内容；真要回退依赖，必须用 Git 恢复 lock + 重装 vendor。
Git 合并冲突时 composer.lock 怎么处理
不能手动合并。它的结构是完整依赖图的序列化结果，字段顺序、缩进、嵌套层级都参与哈希计算，任意“凑合”都会导致后续 install 失败或类加载异常。
标准做法只有三步：
- 任选一方恢复：
git checkout --ours composer.lock（保留当前分支）或git checkout --theirs composer.lock（采纳对方分支） - 清空
vendor/ - 运行
composer install—— 它会基于当前composer.json和刚恢复的 lock 校验一致性，若不匹配会立刻报错，逼你决策：是更新 lock 还是修正 json
最常被忽略的一点：冲突解决后不删 vendor，直接跑 install，很可能沿用旧包导致行为漂移 —— vendor 目录必须和 lock 文件严格对齐，差一个字节都不行。
