github/gitlab https token 认证必须通过 github-oauth 或 gitlab-oauth 配置项设置，域名需严格匹配，不可塞入 url 或 http-basic；token 需 repo 权限，auth.json 权限须 600、utf-8 无 bom。
GitHub/GitLab 的 HTTPS Token 认证必须用 github-oauth 或 gitlab-oauth
Composer 不会自动把任意 Token 当作 HTTPS 凭据使用。对 GitHub 私有仓库，必须通过 github-oauth.github.com 配置项写入；GitLab 则对应 gitlab-oauth.gitlab.example.com（域名需完全匹配）。直接把 Token 塞进 URL（如 https://token@github.com/…）或塞进 http-basic 里，都会失败。
常见错误现象：Could not fetch https://api.github.com/…: Failed to decode response: Syntax error 或静默卡在 “Downloading” 后超时——本质是 OAuth 流程在 HTTPS 跳转阶段中断，而非 Token 本身无效。
- 生成 Token 时必须勾选
repo权限（GitHub 经典 Token）或等效的细粒度权限（如packages:read+contents:read） - 执行命令时不要加引号包裹 Token：
composer config --global github-oauth.github.com abc123def456，加了单/双引号可能导致空格或转义问题 - 验证是否生效：运行
composer config --global github-oauth.github.com，应原样输出 Token 字符串；若为空，说明没写进去或写到了项目级配置里
auth.json 中的 http-basic 只适用于基础认证页面，不是通用 Token 容器
如果你的私有仓库（比如自建 Artifactory、Nexus 或内部 Packagist）提供的是一个需要用户名/密码登录的 HTTP Basic 认证页（返回 401 Unauthorized 并带 WWW-Authenticate: Basic 头），才该用 http-basic。它和 GitHub OAuth 是两套机制，混用必错。
典型误配：把 GitLab Personal Access Token 写进 http-basic.gitlab.example.com → 结果仍是 401；正确做法是用 gitlab-oauth.gitlab.example.com 或 gitlab-token.gitlab.example.com（取决于 GitLab 版本和启用的认证方式）。
- 域名必须严格匹配仓库 URL 的 host:port 部分，例如
https://gitlab.internal:8080/foo/bar.git对应 key 是"gitlab.internal:8080"，不能写成https://gitlab.internal或gitlab.internal -
auth.json文件权限必须是600（Linux/macOS），否则 Composer 直接跳过读取，不报错也不提示 - 编码必须为 UTF-8 无 BOM，用
file -i ~/.composer/auth.json检查，BOM 会导致解析失败且无明确错误信息
HTTPS 连接失败时，composer diagnose 报的 SSL 错误常掩盖真正的 Token 问题
composer diagnose 默认只测 packagist.org 的 HTTPS 连通性，不校验你私有仓库的证书，但它会在尝试访问 GitHub API 时复用同一套 TLS 栈。所以当你看到 SSL certificate problem: unable to get local issuer certificate，第一反应不该是改 Token，而是先确认系统 TLS 环境是否干净。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
真实影响：即使 Token 正确，SSL 握手失败也会让整个 OAuth 流程卡在第一步（获取授权码重定向），导致后续所有认证逻辑都不触发，日志里只显示连接失败，看不出是证书还是 Token 的锅。
- 快速隔离：临时清空 Token ——
composer config --global github-oauth.github.com ""，再跑composer diagnose。如果这时不报 SSL 错了，说明问题出在 GitHub 的 SNI/OCSP Stapling 环节，跟内网代理或中间人设备有关 - 别信
composer install -vvv里的 “Downloading” 行：它可能已悄悄降级到 HTTP，或跳过证书校验（尤其在secure-http=false下），不代表连接真正安全 - 验证私有源 HTTPS 是否真通：用
curl -Iv https://your-private-repo.com/packages.json看完整握手过程和状态码，比依赖 Composer 日志更可靠
Bearer Token 和自定义 Header 认证要走 bearer 或 custom-headers 配置项
某些私有仓库（如部分 Satis 镜像、定制化 Composer Registry）要求用 Authorization: Bearer xxx 或自定义头（如 X-API-Key）认证。Composer 支持这两种方式，但必须用对应配置项，不能塞进 http-basic 或 github-oauth。
示例场景：你对接一个内部 Composer 服务，文档明确要求请求头带 X-Internal-Token: abc123。此时应配置：
composer config --global custom-headers.repo.internal "X-Internal-Token: abc123"
注意：custom-headers 的值是字符串数组，命令行一次只能设一个头；多个头需多次执行，或手动编辑 auth.json。
-
bearer配置结构为{"bearer": {"repo.internal": "abc123"}}，Token 值不带Bearer前缀 - 这些配置不会被
composer diagnose检测，只有在真正请求包元数据时才生效，调试建议配合composer install -vvv观察请求头是否发出 - Bearer Token 通常无域权限限制，但若服务端做了 Referer 或 Origin 校验，可能因 Composer 请求无浏览器上下文而失败
file -i 查编码和 chmod 600 改权限这两步。
