composer.lock 是生产环境依赖版本锁定的唯一有效手段，它通过记录精确版本、哈希值和下载源确保安装一致性；缺失时 install 会退化为 update，导致不可控升级。
composer.lock文件就是生产环境依赖版本锁定的唯一有效手段。没有它，所谓“锁定”只是假象。
为什么 composer install 不等于锁定，而依赖 composer.lock
执行 composer install 时，Composer 会优先检查是否存在 composer.lock。如果存在，就完全按里面记录的版本、哈希值、下载源安装；如果不存在，它会退化为 composer update 行为——重新解析 composer.json 中的约束，生成新锁文件并安装，结果不可控。
- CI/CD 流水线里没提交
composer.lock？那每次构建都可能拉到不同版本，连带触发隐式升级（比如symfony/console从 5.x 升到 6.x） - 本地开发装了
monolog/monolog2.10.0，但同事git clone后跑composer install装出 2.11.0 —— 这说明composer.lock没进 Git - 从 Composer 2.5 开始，如果
composer.lock缺少composer.json里声明的包，install会直接报错：Your lock file does not contain require-dev information或更明确的缺失提示
composer update 是重算依赖图，不是“更新某个包”
运行 composer update monolog/monolog 看似只动一个包，实际会重新评估整个依赖树。只要其他包的约束允许，guzzlehttp/guzzle、psr/log 等间接依赖都可能被连带升级。
- 执行前务必先跑
composer outdated，确认哪些包真有安全更新或兼容性修复 - 升级后必须完整测试（尤其是日志、HTTP 客户端、序列化等基础能力），再提交新的
composer.lock - 若只想升
monolog/monolog但卡住symfony/console在 5.x，得显式加约束："symfony/console": "^5.4"，否则 Composer 会按全局最优解选版本
版本约束写法直接影响锁文件的稳定性
^1.2.3 和 ~1.2.3 语义完全不同：前者允许升到 2.0.0 前任意版本，后者只允许升到 1.3.0 前。生产环境用 ^ 是常态，但必须配合 composer.lock 才真正可控。
-
"monolog/monolog": "dev-master"或"*"是定时炸弹，它们绕过所有 SemVer 控制，CI 报错时很难定位 - 老项目或非标准包不守 SemVer？别硬套
^，改用组合约束，例如">=1.4.0 ，注意中间不能有空格，">= 1.4.0会解析失败 -
minimum-stability设为dev时，*可能装上dev-main，而设为stable时又可能跳过重要补丁——这种隐式行为必须在composer.json里显式声明并文档化
真正容易被忽略的点是：Composer 从不验证你写的约束是否自洽。它只负责在满足全部约束的前提下找一个解。当你看到 Your requirements could not be resolved，问题往往不在某个包本身，而在你同时要求 A 包的 ^3.0 和 B 包的 ^4.0，而它们共同依赖的底层库 C 无法同时满足两个大版本。这时候，锁文件不是万能钥匙，而是暴露矛盾的第一现场。
