^允许主版本不变下的次版本和补丁升级，如^1.2.3等价于>=1.2.3且=1.2.0且
生产环境崩溃的根源，90%以上来自 composer.json 里写了 ^、~ 或 * 却没管住 composer.lock —— 不是约束写得不对，而是没让约束真正生效。
composer.json 中的 ^ 和 ~ 到底允许多大范围更新？
它们不是“建议”，而是 Composer 解析依赖时的真实求解边界：^1.2.3 允许升级到 1.99.99（只要主版本仍是 1），~1.2 等价于 >=1.2.0 。一旦执行 <code>composer update，哪怕只指定一个包，Composer 也会在整个约束图里找最新兼容解——可能把 symfony/console 从 5.4.32 推到 6.0.19，而你的代码还调着 $console->setHelperSet()（v6 已移除）。
常见错误现象：composer update monolog/monolog 后，phpunit/phpunit 版本也变了，本地测试通过但 CI 报 Class 'PHPUnit\Framework\TestCase' not found。
-
^是“向后兼容更新”的默认推荐，但仅对语义化版本严格守约的包有效；现实中很多包主版本跳变不改 MAJOR 号 -
~更保守，适合小版本迭代频繁的工具类库（如ramsey/uuid），但依然不防主版本漂移 - 通配符
*或dev-master在生产环境等于主动放弃控制，必须从composer.json中清除
为什么改了 composer.json 的版本号，线上还是装了新版本？
因为 composer install 根本不看 composer.json 里的约束，它只读 composer.lock。如果你改了 "monolog/monolog": "2.11.0" 却没运行 composer update monolog/monolog，lock 文件里仍是旧版，部署时就装旧版；反之，如果 lock 文件被删或没提交，composer install 会自动 fallback 成 composer update 行为，按新约束重算——此时你写的精确版本才生效，但已是不可控更新。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
关键判断点：ls -l composer.lock 存在且 git status 显示未修改，才是锁定生效的前提。
- CI 流水线中应加检查：
composer validate --strict，它会报错The lock file does not contain require-dev information或Your lock file does not contain a compatible set of packages - 不要用
--ignore-platform-reqs掩盖问题，PHP 扩展缺失应在构建镜像阶段解决，而非部署时绕过 - 若发现线上装的版本和
composer.lock记录不符，优先查composer install是否被误加了--no-lock参数（该参数已废弃但部分旧脚本仍残留）
如何让版本约束真正“锁死”，而不是形同虚设？
靠写法 + 流程双保险：在 composer.json 中用精确版本号（如 "2.11.0"），同时确保 composer.lock 提交到 Git 并在部署时被 composer install 读取。两者缺一不可。
实操建议：
- 对核心框架（如
laravel/framework、symfony/http-kernel）和安全敏感包（如guzzlehttp/guzzle），强制写死"7.5.0"这类带补丁号的完整版本 - 运行
composer update vendor/package --dry-run预览变更，重点看输出里是否出现非目标包，尤其是psr/*、symfony/*、doctrine/*这些底层依赖 - 用
composer show vendor/package确认当前安装版本，再对比composer.lock中对应项的version字段，二者必须完全一致 - 禁止在部署脚本中出现
composer update，哪怕加了包名参数——生产环境只允许composer install --no-dev --optimize-autoloader
最易被忽略的一点：PHP 版本升级会间接让 composer.lock 失效。比如从 PHP 8.1 升到 8.2 后，某些包的 platform 依赖（如 ext-gd）校验失败，composer install 会拒绝执行，此时不能删 lock 文件硬上，而应先在新环境中重新生成 lock（在 CI 构建机上跑），再部署。
