必须验证composer.lock是否被.gitignore排除，否则上线时install将退化为不可控update；CI需硬性检查其存在且受Git跟踪，禁用update，强制使用install --no-dev等参数确保部署一致性。
上线前必须验证 composer.lock 是否被 gitignore 排除
只要 .gitignore 里有一行 composer.lock，或者团队有人漏提交它，上线时 composer install 就会退化为全量解析依赖——这不是“可能出问题”，是“一定装错版本”。CI 流水线第一步必须加检查：
-
ls -la composer.lock—— 确认文件存在且非空 git ls-files --error-unmatch composer.lock > /dev/null || (echo "ERROR: composer.lock not tracked" && exit 1)
GitLab CI 或 GitHub Actions 中，这个检查不能只靠人工 review，得写进 job script 里硬性拦截。
功能分支必须隔离依赖变更，禁止多人同时改 composer.json
两个开发各自在主干上执行 composer require，哪怕装的是不同包，composer.lock 也会因包顺序、哈希排列差异触发 Git 冲突。这不是内容矛盾，是格式扰动。
- 所有依赖增删/升级必须在独立功能分支完成，且只允许一个
composer.json+composer.lock提交 - 在
composer.json根节点加"config": {"sort-packages": true}，强制 lock 文件按字母序排列，消除“假冲突” - 合并前跑一次
composer install --dry-run，确认 lock 与 json 无偏差
CI/CD 中禁用 composer update，只允许 install --no-dev
composer update 在流水线里等于主动放弃锁定——它会忽略 lock 文件、重新求解依赖树、拉取最新 patch 版本，哪怕只是 monolog/monolog 从 2.10.0 升到 2.10.1，也可能因底层行为变更导致日志丢失或格式错乱。
立即学习“PHP免费学习笔记（深入）”；
- 部署命令固定为：
composer install --no-dev --optimize-autoloader --no-interaction --no-progress - CI 镜像中不应预装 Composer，或至少禁止执行任何
composer update类命令 - 上线前最后一道卡点：用
composer audit扫描composer.lock，拦截已知 CVE 包（如guzzlehttp/guzzle的 CVE-2025-xxxx）
lock 文件冲突发生时，不手动合并，只重生成
Git 显示 composer.lock 冲突时，别打开编辑器删 composer.json 为准重新生成。
- 先
git checkout --theirs composer.json（或手动合并 json，确保所有新增包都在） - 删掉本地
vendor/和composer.lock - 执行
composer update --lock（不是install），它只更新 lock 文件，不重装包 - 再
composer install验证能否成功，最后提交新 lock
真正难的不是操作步骤，而是让所有人接受“lock 文件不是文本，是二进制契约”——它不该被 diff，只该被替换。
