公开项目中绝不能提交auth.json或硬编码私有镜像源，因Composer无环境隔离机制；安全做法是仅配置公开镜像（如https://mirrors.aliyun.com/composer/），禁用packagist.org fallback，并确保composer.lock不含内网dist.url。
公开项目里不能存任何镜像源的敏感配置，否则等于把内网地址、认证凭据或私有源路径直接暴露给所有人。 这不是“要不要”的问题，而是 Composer 本身不支持对 repositories 或 auth.json 做条件加载或环境隔离——一旦提交进 Git，就全量可见。
为什么 auth.json 绝对不能进版本库
很多团队把 auth.json 放进项目根目录，以为加个 .gitignore 就安全了。但实际踩坑点在于：
- 新人 clone 后常手动创建
auth.json并提交，尤其在 CI 脚本里用echo写入时极易误提交 -
auth.json里的 token 或密码一旦泄露，攻击者可直接拉取所有租户级私有包，甚至反向探测组织架构 - Composer 不校验
auth.json权限，Linux 下若设为644，Web 服务可能意外暴露该文件（如 Nginx 配置错误）
项目级 repositories 字段怎么写才不算“硬编码”
如果必须让公开项目能走镜像（比如加速 CI），又不能暴露真实源地址，唯一合规做法是：只配元数据镜像，且确保它不带任何认证、不指向内网、不转发私有包列表。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用阿里云或腾讯云等公开 HTTPS 镜像：
https://mirrors.aliyun.com/composer/，末尾必须带/ - 禁用 packagist.org 的自动 fallback：
"packagist.org": false必须显式放在repositories数组首位 - 整个
repositories必须是数组（[]），不能是对象（{}），否则后续命令会清空已有配置 - 示例结构（安全）：
[{"packagist.org": false}, {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}}]
CI 环境中如何注入私有源而不污染代码
GitHub Actions、GitLab CI 或宝塔计划任务里，私有源配置必须运行时注入，且生命周期严格限定在当前 job。
- 用
composer config http-basic.repo.example.com $USERNAME $TOKEN --global动态写入全局配置，不碰项目文件 - 避免使用
--repository-url：它只对update和require生效，install仍读composer.lock里的旧 URL - Docker 构建时，在
RUN阶段前先mkdir -p /root/.composer，再写入auth.json，构建完立即删除中间镜像层 - 永远不要在
composer.json里写"type": "vcs"指向内网 Git 地址——这等于把公司域名和仓库路径打在公网上
最常被忽略的一点：即使你把镜像源地址设成公开的，只要 composer.lock 里某个包的 dist.url 指向内网 ZIP 地址（比如 http://gitlab.internal/packages/foo.zip），这个 lock 文件就永远不能公开。它必须由 CI 在可信环境中生成，并单独存档，不随代码提交。
