Composer install 报401是因为访问私有包时未提供有效认证凭据；需为GitHub配置PAT令牌（含read:packages权限），或为GitLab等配置HTTP Basic Auth，并清除缓存验证生效。
为什么 composer install 突然报 401？
因为 Composer 访问私有包（比如 GitHub 私有仓库、GitLab、Packagist.org 的私有包，或公司内网的私有源）时，没带有效凭据。它默认只用匿名方式请求，而私有资源会直接返回 401 Unauthorized。不是网络问题，也不是 Composer 坏了，就是“没带钥匙敲门”。
怎么配 GitHub 的个人访问令牌（PAT）？
GitHub 已停用密码认证，必须用 PAT；且该 token 必须带 read:packages、delete:packages（如需发布）、write:packages（如需推送）权限。配置错权限或过期都会继续 401。
- 生成 token：去
https://github.com/settings/tokens/new，勾选read:packages（最低要求） - 写入全局凭证：
composer config -g github-oauth.github.com <your_token_here></your_token_here> - 验证是否生效：
composer config -g github-oauth.github.com应输出 token 前几位（Composer 会自动掩码） - 注意：如果项目
composer.json里写了"repositories"指向github.com/xxx/yyy，但没声明"type": "vcs"，Composer 可能绕过 OAuth 走匿名请求——此时要加"type": "vcs"显式声明
私有 Packagist 或 GitLab 怎么配 HTTP Basic Auth？
这类服务通常不走 OAuth，而是用用户名 + 密码（或 token）做 Basic Auth。Composer 支持在 URL 里嵌入凭证，但必须用 composer config 存进 auth.json，否则明文泄露风险高。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 例如 GitLab 私有包地址是
https://gitlab.example.com/api/v4/groups/my-group/-/packages/composer，先确认该源支持 Composer repository 协议 - 生成 auth.json：
composer config -g http-basic.gitlab.example.com username your_personal_token（密码字段填 token） - 如果域名含端口（如
gitlab.example.com:8443），必须把端口也写进 key：http-basic.gitlab.example.com:8443 - 别手动编辑
auth.json—— Composer 对 JSON 格式敏感，一个逗号错误会导致所有认证失效，且错误提示仍是模糊的 401
为什么配了还 401？检查这三处
最常被忽略的是作用域和缓存。Composer 不会实时刷新认证状态，尤其在切换 token 或改源之后。
- 运行
composer clear-cache：旧的 401 响应可能被缓存，导致新配置不生效 - 检查
composer.json里的"repositories"是否覆盖了全局源配置；如果写了{"type": "composer", "url": "https://private.repo"}，就得单独为这个url配http-basic，不能只配composer config -g - 用
composer diagnose查看是否报告 “Authentication failed” 类提示；它不会告诉你哪一行错，但能确认 auth.json 解析是否成功
私有源的认证逻辑其实是分层的：全局配置 → 项目级 auth.json → URL 内联凭证 → 完全匿名。容易漏掉中间某一层的配置，结果卡在最外层失败上。
