必须提交composer.lock文件并用composer install --no-dev --no-interaction部署，禁止误用composer update；锁定包需写死版本、同步执行composer update、验证版本与锁文件一致性。
PHP框架快速部署时，必须确保所有服务器和开发机安装完全一致的依赖版本，否则框架行为可能因底层组件差异而崩溃。这不能靠口头约定或文档说明，只能靠composer.lock文件与严格的操作流程来强制保障。
生成并提交composer.lock文件
首次初始化项目依赖时，在项目根目录执行：
composer install
该命令会读取composer.json中的依赖声明，解析出满足约束的最优版本组合，并自动生成composer.lock——它记录了每个包的确切版本号、SHA-256哈希值、下载地址及完整依赖路径。
【必须将composer.lock提交到Git】：不提交等于没锁。团队成员拉取代码后若缺少该文件，执行composer install将退化为重新解析依赖，极大概率装上不同版本。
立即学习“PHP免费学习笔记（深入）”；
提交命令示例：
git add composer.lock
git commit -m "chore: lock dependencies for Laravel 11.2.0 stack"
生产环境严格按锁文件安装
在CI/CD流水线或生产服务器上，永远只运行：
composer install --no-dev --no-interaction
这条命令跳过require-dev中的开发依赖，不等待用户输入，且完全忽略composer.json中的版本约束，只忠实还原composer.lock中记录的每一个字节级状态。
如果误用composer update，会强行重算依赖树、覆盖lock文件、引入未经测试的新版本——这是线上事故高频诱因。
锁定特定包不被更新
方法一：精确版本写死（最稳）
编辑composer.json，在require区块中把目标包写成纯数字版本，例如：
"laravel/framework": "11.2.0"
⚠️ 不要写"^11.2"、"~11.2.0"或"11.2.*"——这些全是范围约束，update时仍会升级。
方法二：更新锁文件使其生效
改完composer.json后，必须立即执行：
composer update laravel/framework
这一步不可省略。只改json不跑update，composer.lock里仍是旧版本，部署时毫无效果。
方法三：临时跳过更新（仅限单次操作）
Composer 2.2+ 支持：
composer update --ignore=laravel/framework
注意：--ignore不解除依赖关系校验。若其他已装包要求更高版Laravel，仍会报冲突，而非静默跳过。
验证锁定是否真正生效
第一步：检查当前安装版本
composer show laravel/framework | grep version
输出应为"version : 11.2.0"，而非"11.2.1"或"11.x-dev"。
第二步：触发一次无变更更新
composer update laravel/framework
若终端显示"Nothing to install or update"，说明该包已被完全锁定；若提示"Updating laravel/framework (11.2.0 => 11.2.1)"，则锁定失败，需回头检查composer.json写法和lock文件同步状态。
第三步：强制校验锁文件完整性
composer install --locked
该命令不安装任何包，仅比对composer.lock中每个包的版本是否仍满足composer.json中的约束条件。不满足则直接报错退出，防止带缺陷的lock文件流入部署流程。
