composer install 更适合团队部署，因为它严格按 composer.lock 文件还原依赖版本，确保环境一致性；而 composer update 会重新解析依赖树，可能导致版本不一致和 bc break。
为什么 composer install 比 composer update 更适合团队部署
因为 composer.lock 文件锁定了每个包的确切版本（包括子依赖的完整嵌套版本），composer install 会严格按它还原，而 composer.update 会忽略 lock 文件、重新解析依赖树并可能升级到新版本——这正是环境不一致的根源。
常见错误现象：composer update 被误提交进 Git，或 CI/CD 流程里用了 update 而非 install，导致线上跑的代码和本地开发时行为不一致（比如某次小版本更新引入了 BC break）。
- 所有团队成员和 CI 环境必须只运行
composer install（不带参数） - CI/CD 的构建脚本里禁止出现
composer update，除非是专门做依赖审计的独立任务 -
composer install --no-dev在生产环境用没问题，但前提是composer.lock本身已包含 dev 依赖的锁定信息（它默认包含） - 如果项目用了
platform配置（如"php": "8.1.0"），不同机器 PHP 版本不一致时，composer install可能静默降级选择兼容版本——这不是 lock 失效，而是平台约束生效，需统一基础运行环境
哪些修改会触发 composer.lock 必须重新生成并提交
只有当 composer.json 中影响依赖解析的字段变更，且你**有意升级或调整依赖**时，才应运行 composer update 并提交新的 composer.lock。
使用场景：添加新包、删除包、修改 require/require-dev 版本约束、更改 platform、启用/禁用 minimum-stability 或 prefer-stable。
- 改了
autoload或scripts字段？不用更新 lock，也不用update - 只改了
name、description、license？完全不影响依赖，lock 文件保持原样 - 执行
composer update monolog/monolog时，其他包版本可能被动变更（因依赖图重算），所以 lock 文件整体重写，必须全量提交，不能只提交部分 diff - 用
--with-dependencies或--with-all-dependencies时，行为更激进，容易带入意外版本，建议先在 CI 上验证通过再合入
CI/CD 中校验 composer.lock 是否过期的实操方式
不是靠人眼检查，而是让机器自动判断：当前 composer.json 是否与 composer.lock 冲突。冲突意味着有人改了 json 却忘了运行 update 和提交 lock，这是最隐蔽的协作陷阱。
错误现象：本地 composer install 报错 “Your requirements could not be resolved”，或 CI 日志里出现 “Dependency resolution failed”，但本地却正常——大概率是 lock 文件没跟上 json 修改。
- 在 CI 脚本开头加一行：
composer update --dry-run --no-interaction，非零退出即表示 lock 过期，立刻失败 - 不要用
composer install --dry-run，它不检测 json-lock 不一致，只会检查 lock 文件是否存在 - Git hooks（如 pre-commit）也可以加这个检查，但要注意开发者本地 PHP 环境可能没装某些扩展，导致
--dry-run误报；CI 环境更干净，更适合做这步 - 如果项目用了
composer.lock的content-hash字段（现代 Composer 默认有），它本身就能防篡改，但不能替代“json 是否匹配 lock”的逻辑校验
多人协作时 composer.lock 合并冲突怎么安全处理
lock 文件是二进制安全的纯 JSON，但 Git 合并时常产生文本冲突，不能靠手动删块解决——结构错一点，composer install 就直接失败。
核心原则：不编辑 lock 文件内容，只靠 Composer 重生成。
- 遇到冲突，先
git checkout HEAD -- composer.lock回退到当前分支版本 - 然后运行
composer update --lock（Composer 2.2+ 支持），它只重写 lock 文件，不改动任何composer.json中的 require 字段 - 如果用的是老版本 Composer，就用
composer update --dry-run确认无意外变更后，再执行composer update，接着立即git add composer.lock - 绝对不要复制粘贴别人的 lock 片段，也不要手工修复
packages数组里的 hash 值——哪怕看起来只是改了个逗号
真正难的不是操作步骤，而是让所有人理解：lock 文件不是“配置”，它是依赖快照，它的权威性来自生成过程，而不是内容可读性。
