Composer安装SDK失败常见原因包括未发布到Packagist、私有仓库未配置、PHP版本或扩展不匹配；调用失败多因base_uri错位、凭证硬编码、认证头不匹配；升级需关注CHANGELOG中的破坏性变更；极简接口可手写替代SDK。
Composer 安装 SDK 组件失败：常见原因和解法
不是所有 SDK 都能直接 composer require 成功，尤其当它没发布到 Packagist、用了私有仓库、或 PHP 版本/扩展不匹配时，会卡在依赖解析或下载阶段。
- 先确认 SDK 是否真在 Packagist 上：打开
https://packagist.org/packages/{vendor}/{package}查看是否存在、是否支持你当前的 PHP 版本（比如php: ^8.1） - 如果 SDK 是 GitHub 仓库但没注册到 Packagist，需手动加仓库源：
composer config repositories.my-sdk vcs https://github.com/vendor/sdk-name，再composer require vendor/sdk-name - 遇到
Your requirements could not be resolved，大概率是已有包锁定了旧版guzzlehttp/guzzle或psr/http-client，用composer why guzzlehttp/guzzle看谁在拦路，必要时加--with-all-dependencies - 某些 SDK 强制要求
ext-curl或ext-json，运行php -m | grep -E "curl|json"确认已启用
第三方接口 SDK 初始化后调不通：认证和 endpoint 常见错位
装完只是第一步，90% 的“调用失败”其实出在初始化配置上，而不是代码逻辑。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 别直接抄文档里的
new Client(...)示例——很多 SDK 要求把base_uri写成带版本号的完整地址（如https://api.example.com/v2/），而文档只写https://api.example.com，漏掉/v2/就返回 404 - App ID / Secret 不能硬编码进代码，应从环境变量读取：
getenv('THIRD_PARTY_APP_ID')；否则本地能跑，上线后因 .env 未部署直接报Invalid credentials - 部分 SDK 默认用
Bearer，但接口实际要API-Key头，得显式传headers => ['API-Key' => 'xxx']，不能依赖 SDK 自动适配 - 调试时加日志：用
->onStats(function ($stats) { error_log(json_encode($stats)); })（Guzzle）或 SDK 提供的 debug 模式，看清真实发出去的 URL 和 header
SDK 升级后接口行为突变：兼容性断层在哪
看似只是 composer update vendor/sdk-name，但 v3.x 到 v4.x 可能连类名都改了，或者默认启用了签名验证。
- 查 CHANGELOG.md：重点看
Breaking Changes小节，比如Client::sendRequest()改成Client::request()，或$client->post()返回值从Response变成Promise - 留意默认行为变更：老版 SDK 可能自动重试 3 次超时，新版默认关掉，结果线上突然大量
Connection refused报警 - 签名算法升级很隐蔽：比如从 MD5 改成 HMAC-SHA256，但文档只写“推荐新算法”，不标“强制”，导致测试环境能过，生产环境全 401
- 升级前跑一遍
composer outdated vendor/sdk-name，确认当前锁定版本，并用git diff对比 vendor 目录下 SDK 的 src/ 和旧版差异
不用 SDK 直接对接第三方 API：什么情况下更稳
不是所有场景都值得引入 SDK。有些接口极简（就一个 POST + JSON body），加 SDK 反而多一层抽象、多一个维护负担。
- 当 SDK 文档稀烂、示例全错、GitHub issues 堆满没人回，不如自己用
GuzzleHttp\Client或curl_exec()封一层薄 wrapper - 接口协议简单（如仅需 header 带 token、body 是固定 JSON），手写几行比理解 SDK 的中间件链、事件钩子更快
- SDK 依赖太重（比如拉进来整个
symfony/http-client+psr/cache），而你项目里根本不用缓存，纯属资源浪费 - 注意：手写必须自己处理重试、超时、错误码映射（比如把 HTTP 429 转成
RateLimitException），SDK 已帮你兜底的部分，你得补上
