锁定包版本最直接方式是在composer.json中写死精确版本号，如"monolog/monolog": "2.9.0"，Composer将严格安装该版本且不升级任何补丁；若其他依赖强制要求更高主版本（如^3.0），则触发冲突而非降级，需用composer why-not排查。
用精确版本号锁定不升级
想彻底禁止某个包自动更新，最直接的方式是在 composer.json 里写死版本号，比如 "monolog/monolog": "2.9.0"。Composer 会严格安装且只安装这个版本，连小补丁（2.9.1）都不会拉。适合对稳定性要求极高、已验证过该版本无问题的生产模块。
但要注意：如果其他依赖（比如 laravel/framework）硬性要求 monolog/monolog ^3.0，Composer 会直接报冲突，而不是“降级覆盖”。此时得先查 composer why-not monolog/monolog:2.9.0 看谁在拦路。
用插入符（^）和波浪号（~）控制升级边界
^2.9.0 和 ~2.9.0 看似相似，行为差异很实际：
-
^2.9.0允许升到2.99.99，但不会跨到3.0.0—— 这是 SemVer 下的“向后兼容更新”默认策略 -
~2.9.0更窄：等价于>=2.9.0 ，只允许 <code>2.9.x范围内更新，连2.10.0都不放行
多数官方包推荐用 ^；如果你维护的是 SDK 或中间件，且下游明确只适配 2.9.x 的 API 细节，就该用 ~。
用范围约束应对多主版本共存
有些包（如 psr/log）长期维护多个主版本，项目可能同时被 symfony/console ^5.4 和 laravel/framework ^10.0 引入，它们分别依赖 psr/log ^1.0 和 ^3.0。这时光靠 ^ 不够用，得手动放宽约束：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 写成
"psr/log": "^1.0 || ^2.0 || ^3.0"，让求解器有选择空间 - 避免用
*或dev-main，它们会绕过 SemVer 安全边界，CI 构建可能每天都不一样 - 加了多版本约束后，务必跑
composer update psr/log --dry-run预览实际选中哪个版本
更新时别跳过 --with-dependencies 参数
执行 composer update monolog/monolog 只改它自己，它的子依赖（比如 psr/log）可能还卡在旧版，运行时报 Class not found 是常见结果。
正确做法是：
- 单点升级带直系依赖：
composer update monolog/monolog --with-dependencies - 升级整个依赖树（谨慎）：
composer update monolog/monolog --with-all-dependencies - 不加参数的
composer update在任何自动化流程里都该禁用——它等于放弃 lock 文件的确定性
复杂项目里，一个包的版本变动常牵扯三层以上依赖链，只盯 composer.json 里的那行版本号远远不够。
