Composer 卡在 keychain 认证上是因为 macOS Keychain 中存有过期、错误或权限受限的 Git 凭据，导致 git 静默失败；需运行 git credential-osxkeychain erase 清理对应 host/protocol 的凭据，并用 PAT 替代密码，同时确保 keychain 条目设为“允许所有应用访问”。
为什么 Composer 会卡在 keychain 认证上？
Composer 在 macOS 上执行 composer install 或 composer update 时，若遇到私有 Git 仓库（如 GitHub/GitLab），会尝试用 HTTPS 克隆。此时系统默认调用 git，而 git 又依赖 macOS Keychain 存储凭证——一旦 keychain 中存了过期、错误或权限受限的凭据，git 就会静默失败，Composer 则表现为卡住、无响应或报错 Could not fetch https://.../info/refs?service=git-upload-pack。
如何清空并重置 Git 的 keychain 凭据？
别改 Composer 配置绕开认证，先清理源头。macOS 的 keychain 权限策略很严格，旧凭据常被标记为“仅限 git 访问”，但实际已失效。
- 运行
git credential-osxkeychain erase，然后输入：
host=github.com protocol=https
- 对其他域名重复操作，比如
host=gitlab.com、host=your-private-git.example.com - 验证是否清空：执行
git credential-osxkeychain find并输入相同 host/protocol，应无输出 - 之后首次
git clone https://github.com/xxx/yyy.git会弹窗要求重新输入账号密码（或 token）——务必勾选 “Remember this password in my keychain”
为什么推荐用 Personal Access Token 而非密码？
GitHub 已停用账户密码登录 Git，GitLab 等也逐步弃用。用密码会直接失败；用 PAT（Personal Access Token）才能通过 keychain 正确存储和复用。
- 生成 PAT 时至少勾选
repo（私有库）和read:packages（若用 GitHub Packages） - 在 keychain 弹窗中，把 PAT 粘贴进“Password”栏，用户名填你的 GitHub 账号（不是邮箱）
- 如果仍失败，检查 keychain 条目是否被标记为“Access Control” → “Allow all applications to access this item”（否则 Composer 启动的 git 子进程可能被拒绝读取）
Composer 自身是否需要额外配置？
通常不需要。Composer 本身不直连 keychain，它调用 git 命令，所以只要 git 能正常拉取，Composer 就没问题。但有两个边界情况要注意：
- 如果你在 CI 环境（如 GitHub Actions）中遇到类似问题，不要依赖 keychain —— 改用
git config --global url."https://${GITHUB_TOKEN}@github.com/".insteadOf "https://github.com/" - 本地开发中若长期只用 SSH，可全局禁用 HTTPS：运行
git config --global url."git@github.com:".insteadOf "https://github.com/"，这样 Composer 就根本不会触发 keychain
真正容易被忽略的是 keychain 条目的访问控制权限 —— 它不像 Linux 的 ~/.git-credentials 那样明文可查，出问题时很难联想到是 GUI 权限策略在作祟。
