composer.lock是项目依赖的强制执行快照，非配置开关；它存在时composer install严格按其中精确版本、dist.sha256、source.reference及完整依赖树安装，完全忽略composer.json版本约束，缺失则报错拒绝执行。
composer.lock 不是用来“加锁”的配置开关，而是项目依赖的强制执行快照——只要它存在，composer install 就只认它写的版本、哈希、commit，composer.json 里的 ^2.0 或 ~3.1 全部失效。
新项目第一次运行 composer install 为什么报错 “No composer.lock file present”
这不是提示你“该生成一个”，是明确拒绝执行。因为 composer install 的设计定位就是「还原」，它不解析 composer.json，只读 composer.lock。
- 新项目必须先跑
composer update（不是install），它才会根据composer.json解析依赖、计算版本、下载包，并生成composer.lock - 误删
composer.lock后直接跑composer install，新版 Composer（v2.5+）会报Command "install" is not defined；旧版可能静默失败，但vendor/一定不对 - CI 脚本里漏传
composer.lock，等同于放弃环境一致性——不同构建节点可能装出完全不同的guzzlehttp/guzzle小版本
composer.lock 里真正决定安装行为的字段有哪些
别被 JSON 结构吓住，关键就三块：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
packages和packages-dev：分别锁定生产/开发依赖。composer install --no-dev只读前者 - 每个包下的
version：精确到"2.9.1"，不是"^2.0"；dist.sha256或source.reference：决定下哪个压缩包、校验是否完整、检出哪个 commit -
content-hash：由composer.json全文（含空格、顺序）生成；改了 json 却没composer update，这个值就不匹配，composer install会警告但不阻止（除非启用了 lock 校验）
Git 合并冲突时能不能手动编辑 composer.lock
不能。它不是普通 JSON，是整个依赖树的序列化结果，字段顺序、嵌套层级、空格都参与哈希计算。
- 手动删
或改字段顺序，等于直接炸掉依赖契约，后续 <code>composer install可能报JSON decode error或类加载失败 - 正确做法是先用
git checkout --ours composer.lock或--theirs恢复任一干净版本 - 然后删掉
vendor/，再跑composer install——如果当前composer.json和所选 lock 不一致，会立刻报错，逼你确认到底要哪套依赖 - 若只是想对齐 lock 和当前
vendor（比如你本地改过包但没更新 lock），用composer update --lock，它只重写 lock 文件，不装不卸不升级
最容易被忽略的是：composer.lock 不是日志、不是缓存、也不是配置文件，它是部署契约。一旦提交到 Git，就等于签了合同：CI、测试机、生产服务器，谁都不能擅自改依赖树。删了它再重建，不是“重装一遍”，而是把整个依赖树重抽一次签——可能引入未经测试的补丁、不兼容变更，甚至带漏洞的旧包。
