必须提交 composer.lock，否则项目在不同环境必然出现依赖不一致；composer install 严格按 lock 安装，update 则重解析并更新 lock；CI/CD 必须用 install 保证可重现性。
不提交 composer.lock，你的项目在别人机器上大概率跑不起来，或者某天 CI 突然失败——这不是概率问题，是必然结果。
为什么 composer install 和 composer update 行为完全不同
前者读取并严格安装 composer.lock 中记录的精确版本（含哈希校验），后者忽略 lock 文件，按 composer.json 的约束重新解析、升级并生成新 lock。团队协作中误用 composer update 而未提交新 lock，会导致本地能跑、CI 报错、测试环境行为不一致。
- CI/CD 流水线必须用
composer install（而非 update），否则失去可重现性 -
composer.json里写"monolog/monolog": "^2.0"，lock 文件可能锁定到2.10.2；下次 update 可能升到2.11.0，哪怕只是小版本 - PHP 版本变更、平台扩展（如
ext-intl）缺失时，composer update可能选到不兼容的包版本，而install不会触发重解析
composer.lock 被忽略或损坏的典型表现
常见错误现象：本地 composer install 成功，但队友执行后报 Class not found、Method does not exist，或测试通过率骤降。本质是 lock 文件未提交、被 gitignore 误删、或手动编辑导致 JSON 格式损坏。
- 检查是否被忽略：
git check-ignore -v composer.lock，确认没出现在.gitignore里 - 验证完整性：
composer install --dry-run会校验 lock 与 vendor 是否匹配，不一致则报错 - 修复损坏 lock：
rm composer.lock && composer update --lock（慎用，仅限确认无未提交变更时）
什么时候该改 composer.json 并运行 composer update
不是“想升级就 update”，而是明确需要变更依赖策略时才触发。比如修复安全漏洞（composer audit 提示）、适配新 PHP 版本、或引入某个功能必需的新版组件。
- 升级单个包：
composer update vendor/package-name，避免连带更新其他包 - 锁定 PHP 版本影响：
composer update --with-all-dependencies在切换 PHP 大版本后更稳妥 - 提交前必做：
git diff composer.lock，确认改动符合预期（尤其注意content-hash和各包version字段）
最常被忽略的一点：lock 文件里包含 platform 信息（如 PHP、ext-* 版本），它参与依赖解析。不同机器 PHP 版本不一致时，即使 lock 相同，composer install 也可能失败——这时得靠 config.platform 在 composer.json 中声明目标环境，而不是靠人去对齐本地 PHP。
