Composer 不适合管理商业调用凭证，因其 auth.json 仅用于私有包仓库认证，缺乏细粒度权限控制、用途校验和自动轮换机制；正确做法是通过环境变量在运行时注入凭证，并由 SDK 自行加载，实现安全隔离与可审计性。
Composer 本身不支持、也不该承担商业组件调用凭证（如 API Key、License Token）的分发与管理职责。试图用 composer.json 的 repositories 或 auth.json 统一注入秘钥，不仅违背 Composer 的设计边界，还会在 CI/CD、团队协作和安全审计中引发严重隐患。
为什么 auth.json 不适合存商业调用凭证
auth.json 仅用于认证私有包仓库（如 Git SSH/HTTP Basic），不是通用密钥容器。它的权限模型极其粗粒度：一旦写入，所有依赖安装、更新、甚至 composer show 都会无条件加载它；且 Composer 不校验凭证用途，无法区分「访问 packagist.org 私有镜像」和「调用支付网关 SDK」这类完全不同的安全域。
- CI 环境中若误将
auth.json提交或挂载，会导致凭证硬编码泄露 - 多个商业组件共用同一份
auth.json时，无法做细粒度轮换或吊销 - PHP 进程启动后，凭证常驻内存，无自动过期或刷新机制
真正可行的凭证注入方式：环境隔离 + 运行时加载
商业组件 SDK（如 acme/pay-sdk、vendor/analytics-pro）应自身支持从标准环境变量读取凭证，而非依赖 Composer 注入。这是唯一可审计、可切换、符合 12-Factor 应用原则的做法。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- SDK 初始化时优先检查
getenv('ACME_API_KEY')， fallback 到构造函数参数 - 本地开发：在
.env中设置ACME_API_KEY=sk_live_...，由vlucas/phpdotenv加载（注意：.env 不提交） - 生产环境：通过容器编排工具（K8s Secret / Docker --env-file）或 PaaS 平台（如 Laravel Envoyer、Heroku Config Vars）注入，与代码完全解耦
- CI 流水线：使用平台提供的 secret 变量（GitHub Actions
secrets.ACME_API_KEY），避免写入任何配置文件
如果 SDK 强制要求 Composer 配置怎么办？必须绕开
极少数老旧 SDK（如某些内部封装的 legacy-reporting-client）可能硬编码读取 composer-config-plugin 或自定义 extra 字段。此时不能妥协，必须通过适配层隔离风险：
- 创建独立的包装器类
LegacyReportingClientWrapper，启动时从$_SERVER['LEGACY_REPORTING_TOKEN']读取，而非解析composer.json - 在
composer.json的autoload中注册该类，确保它总在 SDK 加载前就位 - 向 SDK 维护方提交 PR，移除对
composer.json的依赖 —— 这是根治方案
强行把商业凭证塞进 Composer 生态，就像用螺丝刀敲钉子：能动，但每次都会崩刃。
