必须提交composer.lock，它是应用项目依赖的强制契约文件；缺失时composer install退化为不可控的update，导致环境不一致、ci失败及线上故障，且新版composer会直接报错命令未定义。

必须提交，否则团队协作和线上部署就不可控。 它不是“可选缓存”，而是应用项目依赖的强制契约文件——只要它不在 Git 里，composer install 就会退化为 composer update，结果完全不可预测。

为什么 composer install 没 lock 就直接失败

因为它的设计目标就是「还原」，不是「求解」。它只读 composer.lock，完全忽略 composer.json 里的 ^2.0、~3.1 这类约束。

• 缺失 composer.lock 时，新版 Composer（v2.5+）直接报 Command "install" is not defined；旧版可能静默失败，但 vendor/ 内容一定不对
• 误删后跑 composer install，错误提示里说 “run composer install” 是误导——它根本不会帮你重建，只会退出
• CI 脚本里漏传 composer.lock，等同于放弃环境一致性：不同构建节点可能装出 guzzlehttp/guzzle v7.8.1 和 v7.8.3，行为差异可能引发 DNS 缓存 bug 或超时逻辑变更

哪些项目必须提交 composer.lock

区分项目类型，不是凭感觉决定。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 必须提交：Laravel 网站、Symfony API、WordPress 插件后台、CLI 工具等——所有能独立部署的应用型项目
• 禁止提交：发布到 Packagist 的库（如 myvendor/my-utils），它的依赖应由下游项目控制
• 常见误操作：把 Laravel 应用当成库来开发，顺手把 composer.lock 加进 .gitignore；验证方式很简单：git check-ignore -v composer.lock，有输出就说明被忽略了

合并冲突时为什么不能手动编辑 composer.lock

它不是普通 JSON 配置文件，而是整个依赖树的哈希快照——字段顺序、空格、嵌套层级都参与校验。

• 手动删冲突标记、凑版本、格式化缩进，99% 会导致 JSON decode error 或后续 Class not found
• Git 的 --ours/--theirs 是行级选择，但 composer.lock 里 packages 和 packages-dev 必须严格对应 composer.json 的 require 和 require-dev，选错一边就会漏包或装错包
• 正确做法：先 git checkout --ours composer.lock（或 --theirs）恢复任一干净版本 → rm -rf vendor/ → composer install；如果报错，说明当前 composer.json 和所选 lock 不一致，必须重新 composer update

真正容易被忽略的点在于：composer.lock 不是“生成物”，它是部署契约——哪怕你本地没动任何依赖，只要它没进 Git，你就已经把环境一致性交给了网络延迟、镜像源缓存、和 Composer 解析器某次随机的决策逻辑。