真正锁定依赖需同时满足：composer.json 中写死三位版本号（如"2.11.0"）、提交 composer.lock 到 Git、部署时执行 composer install —— 缺一不可。
Composer 锁定依赖不是加个开关或跑个命令就能生效的事，真正起作用的是 composer.json 里写死三位版本号 + composer.lock 提交进 Git + 部署时用 composer install —— 缺一不可。
怎么才算真正锁死了某个包的版本
必须在 composer.json 的 require 里写全三位数字，比如："monolog/monolog": "2.11.0"。写成 "^2.11"、"~2.11"、"2.11.*" 甚至 "2.11" 都不算锁定——这些写法都会让 Composer 在语义化版本兼容范围内自动升级。
"2.11" 在不同 Composer 版本中可能被解析为 2.11.0 或 2.11.x，行为不一致；只有明确写出 2.11.0 才能确保行为确定。
- 改完
composer.json后，必须立刻运行composer update monolog/monolog（指定包名），否则composer.lock不会更新，等于白改 - 验证是否生效：运行
composer show monolog/monolog看输出版本；再跑一次composer update monolog/monolog，如果提示Nothing to install or update，才算锁成功 - 别信
composer.lock文件存在就代表锁住了——它只是快照，本身不“起作用”，真正执行锁定逻辑的是composer install命令
为什么线上部署后依赖还是变了
最常见原因是操作链断了：改了 composer.json 却没执行 composer update 更新 composer.lock；或者更新了 composer.lock 却没提交到 Git；又或者上线时误用了 composer update 而非 composer install。
- 删掉
composer.lock后跑composer install，等同于执行一次composer update，所有依赖都会重新解析 - CI/CD 流水线里用了
composer install --no-lock，会跳过 lock 校验，直接退化为 update 行为 - 本地报
Your lock file is out of sync，说明composer.json和composer.lock对不上；此时该跑composer install（保持现状）还是composer update（接受变更），取决于你是否主动改了 JSON
生产环境部署必须做的三件事
线上不能靠“差不多”——composer install 必须配合 --no-dev、--optimize-autoloader 和 --locked 才算真正落地。
-
composer install --no-dev是硬性要求：它从require-dev中彻底排除包，连 autoload 配置都不注册，避免dump()等函数冲突或类加载失败 -
composer dump-autoload --no-dev --optimize必须在 install 之后单独执行：否则vendor/autoload.php里还留着测试类路径，线上会报Class not found -
composer install --locked是上线前最后一道保险：它校验composer.lock中每个版本是否仍满足composer.json的约束，不满足直接报错退出，不让你稀里糊涂上线
团队协作中最容易被忽略的细节
composer.lock 必须提交到 Git，它是保证开发、测试、生产三端依赖一致的唯一可靠依据；不提交等于把一致性交给运气。
- CI 构建脚本里别写
composer update，哪怕只是“顺手更新一下”——这违背不可变部署原则 - PHP 版本变更会间接导致
composer.lock失效：例如从 PHP 8.1 升级到 8.2 后，某些包的平台约束可能让 lock 文件不再兼容 - 不要依赖
"minimum-stability": "stable"或"prefer-stable": true来替代--no-dev——它们控制版本选择策略，不控制安装范围
真正难的从来不是“怎么写”，而是每次改 composer.json 后，是否同步更新并提交了 composer.lock；以及上线那一刻，服务器上跑的到底是 install 还是 update。
