必须提交composer.lock且不能被.gitignore拦截——应用项目依赖一致性的强制契约；验证用git check-ignore -v composer.lock，有输出即被忽略；冲突时应删lock后运行composer update --no-install重建，而非手动编辑。
必须提交，且不能被 .gitignore 拦截——这是 PHP 应用项目团队协作的底线。 不提交 composer.lock，composer install 就退化为 composer update，不同人、不同时刻、不同 CI 节点装出来的依赖版本大概率不一致，问题会出现在上线前最后一秒。
怎么确认 composer.lock 真正进了 Git？
很多人以为自己提交了，其实早被 .gitignore 拦下。验证方式只有一条命令：
git check-ignore -v composer.lock
如果有输出，说明它被忽略了。常见错误包括：
-
/composer.lock（开头斜杠导致只匹配根目录，但实际路径可能带子目录） -
composer.lock（没加斜杠，可能误匹配my-composer.lock这类文件） - 行首或行尾有空格，比如
composer.lock - 写在全局
~/.gitignore里，而非项目级
删掉所有相关行后，运行 git add -f composer.lock 强制加入暂存区。
Pilot Digital Twin Setup
下载
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
冲突时为什么绝不能手动编辑 composer.lock？
composer.lock 不是配置文件，是依赖图的哈希快照。Git 行级合并（ / <code>======）会直接破坏 JSON 结构，哪怕侥幸通过解析，也会引发静默错误：
- 保留了 A 分支的
laravel/frameworkv10.42.0，但 B 分支新增的spatie/laravel-ray在packages-dev里没写入 →composer install报The lock file does not contain require-dev information - 字段顺序被 Git 自动重排（如
name和version对调），composer validate通过，但后续composer update --lock会重写整块，掩盖真实变更 - 手动删冲突标记、凑出“看起来合理”的版本号 →
dist.sha256校验失败，类加载失败或行为异常
冲突发生后唯一安全的重建流程
核心原则：丢掉 composer.lock，以合并后的 composer.json 为唯一可信源，让 Composer 重新生成。
- 先确保
composer.json已 clean merge：手动解决增删改（比如确认"monolog/monolog": "^3.0"是否该保留） - 删掉本地
vendor/和composer.lock（避免缓存干扰） - 运行
composer update --no-install：只更新 lock，不重装 vendor；重点检查输出里是否有意外downloading行（如guzzlehttp/psr7从 2.6.2 降级到 2.5.0） - 确认无误后
git add composer.lock，提交信息明确描述变更，例如：lock: sync monolog ^2→^3 + php 8.3 platform constraint
怎么减少 composer.lock 的“假冲突”？
Git 标红 composer.lock 不代表依赖变了，大概率是排序或空格差异。关键在统一生成规则：
- 所有人执行
composer config -g sort-packages true，强制packages和packages-dev按字母序排列 - 禁用裸
composer update：只允许composer update vendor/package-name --with-dependencies，避免全量重排触发大面积 diff - CI 中加校验步骤：
composer install --dry-run，失败即阻断 PR 合并——说明有人改了composer.json却没提交新composer.lock
真正容易被忽略的是 content-hash 字段：它由 composer.json 内容计算得出，一旦 JSON 格式（比如换行、缩进）不一致，这个哈希就失效，导致 Composer 认为 lock 文件过期。
