composer.lock 是 Composer 依赖状态的唯一权威快照，不可忽略或手动修改；删后执行 composer install 等价于强制 composer update，导致环境不一致、CI 失败、Class not found 等问题。
Composer 没有叫“快照功能”的独立命令或开关——composer.lock 就是它唯一的、自动生效的依赖快照机制。想靠它保障版本稳定，关键不是“怎么开”，而是“怎么用对、不绕过、不误改”。
为什么删掉 composer.lock 再 composer install 等于强制升级
因为 composer install 的行为完全取决于是否存在 composer.lock：
- 有
composer.lock→ 严格按里面记录的每个包的version、dist.shasum、source.type安装，composer.json中的"^2.0"这类约束被彻底忽略 - 没
composer.lock→composer install会直接报错（除非加--no-lock），此时行为等价于composer update：重新解析所有约束、选最新满足条件的版本、生成新 lock
所以“重装依赖”不等于“恢复快照”，删 lock 文件再 install 是主动放弃快照一致性，极易导致本地能跑、CI 报错、线上 Class not found。
composer show --locked 和 composer show --tree 哪个适合比差异
要看你比什么：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 比“整个项目依赖树是否一致” → 用
composer show --locked --format=json导出，再jq -S .格式化后diff。这是唯一能反映composer.lock全量状态的方式 - 比“某个包及其子依赖在两个环境里装了哪些版本” → 用
composer show --tree vendor/package --no-ansi | sort。它扁平化输出、去颜色、可排序，diff 结果稳定可靠 - 别用裸
composer show：输出受终端宽度、字母序、深度优先遍历影响，每次运行结果都可能不同，diff 必然失效
注意：composer show 不带 --locked 会混入 dev-only 包或本地 path repo，不能代表真实部署态。
CI/CD 中 composer.lock 冲突或未提交，构建失败怎么办
这不是配置问题，是协作流程断点：
- Git 冲突出现在
composer.lock？不要手动合并 JSON 字段。先git checkout --theirs composer.lock（或--ours），立刻composer install验证能否装通；不通说明两边依赖树本质不兼容，必须协调修改composer.json - CI 报错 “package not found in your composer.json” → 大概率是某人提交了
composer.lock，但没同步提交对应的composer.json修改（比如新增了 require 或改了 stability）。这时要回退 lock 提交，或补上 json 变更 - 有人上线前用了
dev-main测试，但没切回稳定版 → 检查 lock 文件里目标包的version字段是不是"dev-main"或含"reference": "a1b2c3d"；上线前必须执行composer require vendor/package:^2.5并提交新 lock
最常被忽略的一点：lock 文件里固化的是 autoload 映射和 dist URL，不只是版本号。哪怕版本号没变，一个包内部目录结构调整后打了新 tag，旧 lock 仍会拉老结构，autoload 自动加载就会失败——这不是 Composer 的 bug，是快照机制本意如此：它锁的是“那一刻的完整交付物”。
