能，但必须分层配置：私有源放repositories数组首位（type为composer或vcs），国内镜像作为packagist替代放第二位并加"packagist": false，顶层设"packagist.org": false彻底禁用默认源，确保ZIP地址也指向内网可直连路径。
私有包和国内镜像能共存吗？能，但必须分层配置
可以，而且必须分层：国内镜像只管公开包（packagist.org 的替代），私有包必须走独立源。Composer 不会自动合并或智能路由，它按 repositories 数组顺序查找，遇到第一个匹配的包就停。所以不能把私有源和镜像混成一个条目，也不能让镜像“覆盖”私有源。
为什么 composer config -g repo.packagist 不能解决私有包问题
这条命令只替换 packagist.org 元数据入口，不影响私有包的解析逻辑。更关键的是：它不改 ZIP 下载地址——私有包的 dist.url（比如 GitLab Release 链接或内部 Satis dist 路径）仍由包自身 composer.json 或私有源服务决定，镜像源对此完全无感知。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
repo.packagist是专用于公开包的“别名”，Composer 内部硬编码识别它，对其他仓库名（如my-company）不做特殊处理 - 私有包若托管在 Git 仓库，type 必须是
vcs；若托管在 Satis/Artifactory 页面，type 必须是composer，且 URL 必须以/结尾 - 漏写
"packagist.org": false就会导致 Composer 先去官方源查一遍，超时后才 fallback 到私有源，白白拖慢整个流程
项目级 composer.json 正确写法
必须同时声明镜像源（作为 packagist）和私有源（自定义名），并显式禁用默认源。顺序很重要：私有源放前面，镜像源放后面，再加全局开关。
{
"repositories": [
{
"type": "composer",
"url": "https://pkgs.internal/"
},
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/",
"packagist": false
}
],
"packagist.org": false
}
- 第一项是你的私有源，
type是composer（不是vcs），URL 末尾必须带/ - 第二项是阿里云镜像，必须带
"packagist": false字段，否则它会被当成普通仓库，不接管公开包 - 顶层
"packagist.org": false是最终保险，强制关闭默认源，避免任何 fallback - 不要用
composer config -g配私有源——它只影响当前用户，CI 和队友都不可见
常见卡顿点：ZIP 包还是从 GitHub 下载？
即使 packages.json 拉成功了，composer install 仍可能卡在 “Downloading” 阶段，因为 ZIP 地址（dist.url）没被代理。验证方式：composer show vendor/package --verbose，看输出里的 dist.url 是否指向内网地址。
- 如果是 Satis 搭建的私有源，确保
satis.json中archive配置启用了"format": "zip"，且 Nginx 正确暴露dist/目录 - 如果私有包是
vcs类型（如 GitLab），Composer 默认走git clone，不会下载 ZIP；想强制 ZIP，得在私有包的composer.json里加"dist": {"url": "https://pkgs.internal/dist/..."} - 所有
dist.url必须能被本地机器直接curl -I成功返回200，否则 Composer 会反复重试直到超时
composer.json 容易格式错乱，而 composer config repo.packagist 命令又无法安全追加私有源。最稳的路径是——用脚本生成 repositories 结构，再用 jq 注入，避免手误。 
