在 composer.json 中真正锁死一个包的正确写法是使用纯数字版本号如 "monolog/monolog": "2.9.1"，不带任何符号；同时必须提交 composer.lock 到 Git，并运行 composer update monolog/monolog 同步锁文件，否则无法保证环境一致。
Composer 锁定版本不升级，靠的不是命令开关，而是 composer.json 里写死版本号 + composer.lock 提交进 Git —— 缺一不可。
怎么在 composer.json 中真正锁死一个包？
很多人以为把 "monolog/monolog": "^2.8" 改成 "^2.8.0" 就算锁了，其实没用。^ 和 ~ 都是范围符号，只要还在语义化版本兼容范围内，composer update 就会升。
- ✅ 正确写法：
"monolog/monolog": "2.9.1"（不带任何符号，纯数字） - ❌ 错误写法：
"monolog/monolog": "^2.9"、"~2.9.0"、"2.9.*"、甚至"2.9"（后者在不同 Composer 版本中解析不一致） - 改完必须立刻运行：
composer update monolog/monolog，否则composer.lock不会同步更新 - 验证是否生效：
composer show monolog/monolog输出应为2.9.1；再跑一次composer update monolog/monolog，若提示Nothing to install or update，才算真正锁住
为什么 composer.lock 必须提交到 Git？
composer.lock 不是缓存文件，它是整个依赖树的“快照”：记录每个包的确切版本、哈希值、完整依赖路径。没有它，composer install 就退化成按 composer.json 重新解析 —— 即便你写了 "2.9.1"，如果 lock 文件不存在或被忽略，CI 或新同事执行 install 时仍可能装上 2.9.2（比如镜像源缓存了新版本）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 团队协作中删掉或 .gitignore 掉
composer.lock，等于主动放弃版本控制 - CI/CD 流水线必须用
composer install --no-dev --no-interaction，绝不能用update - 上线前加一道保险：
composer install --locked—— 它会校验composer.lock中每个版本是否仍满足composer.json的约束，不满足直接报错退出
想临时跳过某个包更新，有哪些安全做法？
日常维护常需更新大部分依赖，但冻结 Laravel、Doctrine 或 Guzzle 这类关键包。这时别碰 composer.json，用命令行精准控制更灵活。
- 只更新指定包（最常用）：
composer update laravel/framework symfony/console—— 漏掉不想动的就行 - Composer 2.2+ 可用
--ignore：composer update --ignore=laravel/framework，但注意：如果其他包依赖更高版laravel/framework，仍会冲突报错 - 用
--dry-run预览变更：composer update --dry-run看清楚哪些包会被升，再决定是否执行 - ⚠️ 别用
--with-dependencies默认开启 —— 它会连带更新所有子依赖，容易意外拉入不兼容版本（比如doctrine/dbal从3.6升到4.0）
高级防护：用 prohibit 或 conflict 主动拦截危险版本
当某个包的新版本已知有严重 bug（比如 guzzlehttp/guzzle >=7.5.0 引发超时逻辑变更），光靠“不升级”不够，得让 Composer 在解析阶段就拒绝安装。
- Composer 2.5+ 支持：
composer prohibit "guzzlehttp/guzzle:>=7.5.0"—— 后续update遇到该范围直接报错中断，不是静默跳过 - 兼容旧版的写法：
"conflict": { "guzzlehttp/guzzle": ">=7.5.0" }，效果类似，但需手动编辑composer.json - ⚠️ 注意：
conflict和prohibit不阻止你显式require冲突版本，所以仍要配合精确版本号使用 - 别滥用
replace声明“已提供”——它不卸载包，只是骗过依赖解析；若没真实实现对应功能，运行时会Class not found
最容易被忽略的是：锁版本 ≠ 锁行为。哪怕 guzzlehttp/guzzle 被锁在 7.4.5，只要它还在 vendor/ 里、且被 autoload 映射，代码里照样能 new 出来；真正的隔离得靠代码层判断或重构调用路径。
