composer.lock 文件是依赖版本锁定的核心机制，必须提交至 Git；执行 composer install 时严格按 lock 文件安装，而 update 才会重新解析版本；CI/CD 中缺失 lock 文件或缓存污染将导致意外升级。
composer.lock 文件不是摆设，它就是版本锁
只要项目里存在有效的 composer.lock 文件，且你用的是 composer install（不是 composer update），所有包就会严格安装 lock 文件里记录的版本。很多人误以为删了 lock 文件或执行 update 就“自动升级”，其实问题出在操作习惯上。
- 团队协作时，
composer.lock必须提交进 Git —— 它不是临时文件，是依赖快照 -
composer install会跳过composer.json中的版本范围解析，直接读 lock 文件安装；而composer update才会重新解析并更新 lock - CI/CD 流程中如果用了
composer install --no-interaction却没提供 lock 文件，就会退化成等效于 update 的行为，导致意外升级
用 exact version 写死 composer.json，但要小心语义化版本陷阱
想彻底禁掉某包的任何变动，最直接的方式是在 composer.json 里写死精确版本号，比如 "monolog/monolog": "3.5.0"。但这不等于绝对安全——Composer 默认仍会检查该版本是否存在兼容的稳定性标签（如 3.5.0@stable），且某些配置可能绕过限制。
- 避免用带波浪号
~或插入符^的写法，比如^3.5允许升到3.9.9，~3.5允许升到3.5.9 - 如果包发布过多个 stability 标签（如
3.5.0-beta1和3.5.0），仅写"3.5.0"可能因minimum-stability设置被忽略，建议同步加"@stable"后缀："3.5.0@stable" - 私有包或 fork 包若未打 Git tag，Composer 可能 fallback 到 commit hash，此时写死版本号无效，得配合
repositories+package类型手动声明
禁止 update 某个包：require 和 require-dev 要分开处理
有时只想锁住一个关键包（如 laravel/framework），其他包仍可小步迭代，这时候不能全靠 lock 文件——因为一旦执行 composer update，默认会更新全部包。必须显式排除。
- 执行更新时用
composer update --with-dependencies不够，真正有效的是composer update "vendor/package" --with-dependencies，只更新指定包及其直系依赖 - 更稳妥的做法是：先
composer update到想要的状态，再用composer prohibit vendor/package（需装composer/prohibitor插件）或手动在composer.json加"conflict": {"vendor/package": "*"}阻止安装任意版本 - 注意
require-dev里的包默认不参与生产环境安装，但如果 CI 跑了composer install --dev，它们也会被装上，所以锁版本逻辑同样适用
CI 环境里最容易漏掉的两个点
本地看着稳，上线却翻车，大概率是因为 CI 没复现本地的安装路径。尤其当 pipeline 里混用了 install/update、缓存策略不一致、或多阶段构建时，lock 文件容易被覆盖或忽略。
- GitLab CI / GitHub Actions 中，确保
composer install前已 checkout 出composer.lock—— 有些 workflow 用 shallow clone，默认不带历史，可能漏掉刚提交的 lock 文件 - 如果用了 Composer 2.2+，检查是否启用了
COMPOSER_CACHE_DIR，旧缓存可能含过期的包元数据，导致 resolve 出错；建议每次 CI 清缓存或用--no-cache - Docker 构建时，
COPY composer.json composer.lock ./必须在RUN composer install之前，且顺序不能颠倒，否则 Docker cache 机制会让 lock 文件变更失效
composer.lock 的敬畏、对命令意图的明确区分，以及在每个部署环节确认「我到底在装什么」。 
