私有包认证严禁硬编码于composer.json，必须通过auth.json或COMPOSER_AUTH环境变量配置；http-basic域名须逐字符匹配，Git仓库需单独处理SSH或Token内联，OAuth权限须按平台精确设置。
私有包认证信息一旦泄露，等于把公司核心代码库的门禁卡贴在 GitHub 上——auth.json 提交进 Git、composer.json 里硬编码 Token、CI 日志打印凭据，这三类操作在 2026 年仍是最常被扫出高危漏洞的配置方式。
为什么不能把认证写进 composer.json
Composer 明确不解析 composer.json 中的认证字段。你哪怕写成 "url": "https://token:abc123@repo.example.com"，Composer 也会在解析阶段直接忽略整个 repositories 条目，或报 Invalid repository type 错误。这不是 bug，是设计限制：它只接受纯元数据，拒绝混入凭据。
- HTTP Basic 认证必须走
auth.json或COMPOSER_AUTH，不能内联 URL -
github-oauth、gitlab-oauth等字段也只被composer config命令识别，不会从composer.json加载 - 有人用
sed替换 URL 占位符（如https://\${TOKEN}@...），但这是临时 hack，且易被日志捕获
auth.json 放哪？怎么写才安全
路径和内容格式错一个字，Composer 就静默跳过认证——既不报错，也不拉包。常见失效点：域名不完全匹配、JSON 格式非法、字段名拼错。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 项目级
auth.json必须和composer.json同目录；全局级在~/.composer/auth.json（Linux/macOS）或%APPDATA%\Composer\auth.json（Windows） - 内容只能是标准 JSON，顶层键必须是
http-basic、bearer、gitlab-oauth等之一，不能多一层包装 -
http-basic的域名必须与仓库 URL 主机名**逐字符一致**：用https://packages.mycompany.com就配"packages.mycompany.com"，配成"mycompany.com"或带端口（packages.mycompany.com:443）都会失败 - 密码字段推荐填 Personal Access Token（GitHub/GitLab），而非账号密码；Token 应设最小权限（如仅
read_package_registry）
CI/CD 中必须用 COMPOSER_AUTH 环境变量
CI 场景下，auth.json 文件写入工作区=凭据落地磁盘，哪怕加 rm -f auth.json 也防不住日志缓存或 artifact 残留。唯一可靠方案是环境变量注入。
-
COMPOSER_AUTH值必须是合法 JSON 字符串，例如：{"http-basic":{"packages.mycompany.com":{"username":"token","password":"ghp_abc123..."}}} - GitHub Actions 中直接写：
COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH }}，Secret 内容就是上面那段 JSON（不要加引号包裹） - GitLab CI 若需 Git clone 私有 VCS 仓库（非 Composer 类型），仅
http-basic不够——得配合before_script注入CI_JOB_TOKEN到composer.json的 URL 中，或用git config设置临时凭证（但后者不可用于并行作业） - 别用
composer config http-basic动态生成auth.json：命令会把凭据写入文件，且可能被composer install --verbose日志输出
Git 仓库拉取失败？检查底层协议是否匹配
当 composer install 报 Cloning into ... fatal: could not read Username 或 Authentication failed，大概率不是 Composer 配置问题，而是 Git 协议层没通。
- VCS 类型仓库（
"type": "vcs"）走的是git clone命令，不是 HTTP 请求——所以http-basic配置对git@或https://Git URL 无效 -
git@地址依赖 SSH key；https://地址需 Git 凭据助手（git config --global credential.helper store）或 URL 内联 Token（https://<token>@gitlab.example.com/group/pkg.git</token>） - GitLab 私有实例若启用了双因素，必须用
CI_JOB_TOKEN替代个人 Token，且 URL 必须带.git后缀，否则 Composer 会降级为 HTTP API 调用而失败 - 调试时可用
git -c http.extraHeader="Authorization: Bearer $TOKEN" clone https://...手动验证是否通
最常被忽略的一点：GitLab 和 GitHub 的 OAuth Token 权限模型完全不同——GitLab 的 api scope 允许读写所有项目，而 GitHub 的精细化 Token 必须显式勾选 read:packages，少一个字母就 403。
