删旧token仍报invalid credentials，因composer读取缓存或错配auth.json：路径错误、json格式非法（如多逗号）、项目级auth.json未被composer.json显式启用；github需classic pat含read:packages，gitlab需api scope而非read_api。
为什么删了旧 token 还报 Invalid credentials？
不是 token 没更新，而是 Composer 仍读着缓存或错配的配置。常见原因有三个：auth.json 路径不对、JSON 格式非法（比如多逗号、单引号）、或者凭据写在了项目级 auth.json 里却试图访问全局私有源。Linux/macOS 下 Composer 默认只认 ~/.composer/auth.json，Windows 是 %APPDATA%\Composer\auth.json；项目根目录下的 auth.json 只影响当前项目，且必须被 composer.json 显式启用（通过 "config": {"auth-file": "auth.json"}），否则直接忽略。
GitHub/GitLab token 权限填错导致 401 怎么查？
GitHub 的 github-oauth.github.com 必须用 Personal Access Token（classic），且至少勾选 read:packages；GitLab 的 gitlab-token.gitlab.example.com 需带 api scope（不是 read_api 或 read_repository）。如果用的是 fine-grained token，旧版 Composer（Invalid credentials。验证方法很简单：curl -H "Authorization: Bearer ghp_xxx" https://api.github.com/user/packages，返回 200 才算真正有效。
怎么安全重配 http-basic 而不暴露密码？
别手写 auth.json，也别在命令行里直接写密码（会进 shell 历史）。用 composer config --global http-basic.packagist.example.com username token，它自动校验 JSON 合法性，且不记录敏感字段到历史。如果是 Magento 这类用公钥/私钥的场景，用户名填公钥（pubkey_abc），密码填私钥（privkey_xyz），注意复制时别带前后空格——粘贴后用 cat ~/.composer/auth.json | jq . 看一眼值是不是字符串开头结尾没空格。
镜像源地址写错也会触发 Invalid credentials
比如把 https://packagist.laravel-china.org 写成 https://packagist.laravel-china.org/（末尾斜杠），某些镜像服务会 302 跳转到登录页，Composer 就误判为需要认证。更隐蔽的是国内镜像崩了（如 packagist.phpcomposer.com 已停服），返回 403 或 HTML 页面，Composer 解析失败后统一抛 Invalid credentials。先跑 composer config -g repo.packagist 确认当前镜像，再用 curl -I https://your-mirror-url/packages.json 看 HTTP 状态码和 Content-Type 是否为 application/json。
最常被跳过的环节是：改完 auth.json 或换完镜像后，忘了删 composer.lock。这个文件锁死了旧的源地址和认证方式，不删它，composer update 依然走老路。
