配github personal access token是唯一可靠解法，不配token就永远卡在每小时60次限流里——换镜像、调超时、改dns都无效；必须用composer config --global github-oauth.github.com 配置带repo权限的token，并设~/.composer/auth.json权限为600，验证需见curl返回rate.limit=5000及install -v日志中“using github token”。
GitHub OAuth Token 配置失败的典型现象
执行 composer install 或 composer update 时卡在私有仓库拉取环节，报错类似：Failed to download vendor/private-package: Could not fetch https://api.github.com/repos/vendor/private-package/zipball/...: Failed to authenticate...；或者提示 Authentication is required 但没给出输入框——这说明 Composer 没拿到有效凭证，不是网络问题，是授权配置缺失或失效。
用 composer config 命令安全写入 Token
GitHub 不再支持密码登录 API，必须使用 Personal Access Token（PAT），且推荐用细粒度令牌（Fine-grained token）并勾选 read:packages 和 read:repository 权限（若需安装私有 repo 中的包）。
不要手动编辑 auth.json 文件——容易格式出错或权限泄露。直接运行：
composer config --global github-oauth.github.com <your-token-here></your-token-here>
这条命令会把 Token 写入全局 auth.json（通常位于 ~/.composer/auth.json），且自动处理 JSON 格式和引号转义。
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 如果只给单个项目用，去掉
--global，在项目根目录下执行（Token 只对该项目生效） - Token 一旦写入，后续所有 GitHub 私有包操作（
install、update、require）都会自动携带认证头 - 验证是否生效：运行
composer config --global github-oauth.github.com，应输出 Token 前几位（Composer 会掩码显示）
细粒度 Token vs 经典 Token 的关键区别
GitHub 自 2022 年起逐步淘汰经典 Token，新创建的细粒度 Token 默认不继承旧权限，必须显式选择资源范围。
- 细粒度 Token 必须勾选
Read-only权限下的Repository permissions → Contents: read，否则无法下载 zipball - 如果包托管在 GitHub Packages（
https://npm.pkg.github.com类 registry），还需额外勾选Packages → Read packages - 经典 Token 虽仍可用，但不支持
github-oauth配置项——它只认细粒度 Token；若误用经典 Token，Composer 会静默失败，不会报错 - 细粒度 Token 支持设置过期时间（建议设为 90 天），到期前需重新生成并更新 Composer 配置
为什么 COMPOSER_AUTH 环境变量不推荐日常使用
虽然可以用 COMPOSER_AUTH='{"github-oauth": {"github.com": "xxx"}}' 启动命令，但它存在三个硬伤：
- Token 会出现在进程列表里（
ps aux可见），CI/CD 日志中也可能被意外打印 - 每次执行都要重复设置，无法持久化，不适合本地开发流
- 如果值里含特殊字符（如
/、=），shell 解析易出错，不如config命令可靠
它只适合临时调试或容器环境注入，别把它当主力方案。
细粒度 Token 的权限粒度很细，漏选一个 scope 就会静默失败；而 Composer 对认证错误的提示又极其简陋——这是最常被忽略的复杂点。
