Composer管理依赖的关键是“声明+锁定+加载”三环闭环：用composer.json声明依赖，靠composer.lock锁定精确版本，再通过vendor/autoload.php自动加载类；漏掉任一环将导致环境不一致、版本错乱或安全风险。
直接说结论：Composer 管理依赖不是“装完就完事”，关键在 composer.json 声明、composer.lock 锁定、vendor/autoload.php 加载这三环闭环。漏掉任一环，轻则本地能跑线上炸，重则团队协作时版本错乱、安全漏洞潜伏。
初始化项目时，composer.json 怎么写才不踩坑
别用 composer init 交互式生成后就直接开干——它默认把最低稳定版设为 stable，但很多包（如 phpunit/phpunit）的 dev-main 分支其实更健壮；而且它不强制校验 PHP 版本兼容性，容易引入不支持当前环境的包。
- 手动创建
composer.json更可控，至少包含name、type、require和autoload -
require里别写"monolog/monolog": "1.0.*"这种过时写法，改用"^2.10"或"~3.0.0"，语义清晰且防意外升级 - 务必加
"config": { "platform": { "php": "8.2.10" } }，防止 CI 环境 PHP 版本略高导致解析出错 - 写完立刻运行
composer validate，它会报出 JSON 语法错误、字段缺失、PHP 版本冲突等真实问题
composer install 和 composer update 到底该用哪个
这两个命令行为差异极大，混用是线上事故高频原因。核心区别不在“装”还是“更新”，而在“是否重新求解依赖图”。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install：只读composer.lock，安装其中记录的**精确版本号**（比如"monolog/monolog": "3.5.0"）。没 lock 文件？它会先按composer.json求解并生成 lock，但结果不可复现 -
composer update：彻底丢弃 lock 文件，重新从composer.json的版本约束出发，拉取所有满足条件的最新版本，再生成新 lock。全量执行等于主动放弃版本控制 - 日常开发加依赖，用
composer require guzzlehttp/guzzle:^7.5—— 它自动写入composer.json、更新composer.lock、下载包，一步到位 - 只想升级某个包？明确指定名字：
composer update doctrine/dbal，避免连带升级symfony/console导致命令行工具异常
生产环境部署时，--no-dev 和 --optimize-autoloader 必须加
不加 --no-dev，phpunit、php-cs-fixer 全部打进线上 vendor，不仅体积翻倍，还可能因调试工具暴露 var-dumper 调试接口，被扫描器抓到就是 RCE 风险。
- 部署命令必须是：
composer install --no-dev --optimize-autoloader --apcu-autoloader -
--optimize-autoloader把 PSR-4 映射转成静态数组，类加载快 3–5 倍；--apcu-autoloader进一步缓存到 APCu，适合 PHP-FPM 场景 - CI/CD 流水线中，要确保
composer.lock已提交 Git，且composer install命令前检查git status --porcelain，防止有人绕过 lock 直接改composer.json提交
依赖解析失败时，Your requirements could not be resolved 怎么快速定位
这句报错不是 Composer 报错，而是依赖求解器（Solver）给出的最终结论。它背后往往有具体冲突点，但默认输出太简略。
- 先加
-v参数重试：composer update -v，看最后几屏的Problem 1具体指出哪个包和哪个版本范围冲突 - 常见真凶是平台包（
ext-mbstring、ext-xml）未启用，或php版本约束和某依赖不兼容，此时composer diagnose会直接告诉你缺什么扩展 - 如果冲突来自私有包或 VCS 仓库，确认
repositories字段里用了"type": "vcs"而不是"type": "package"，后者不支持分支解析 - 临时绕过（仅调试）：
composer update --with-all-dependencies强制连带升级子依赖，但上线前必须回退并真正解决约束冲突
最常被忽略的一点：composer.lock 不是“中间产物”，它是生产环境的契约文件。删了它、改了它、或者不提交它，等于把版本控制权交给了网络延迟和 Packagist 的元数据缓存。
