Composer不提供加密解密能力，auth.json中token或private-key以明文存储并直接透传；private-key需为完整PEM格式字符串，github-oauth仅用于API请求，HTTP拉取源码需http-basic或GITHUB_TOKEN，文件权限644及CI缓存导致泄露风险极高。
Composer本地配置里私钥和Token怎么被读取的
Composer不会自动解密任何敏感字段——auth.json 里的 token 或 private-key 字段，只要没手动加密，就以明文形式存在磁盘上。所谓“解密提取”，其实是误传；Composer本身不提供加密/解密能力，它只按需读取并透传给对应仓库（如 GitHub、GitLab、私有 Packagist）。
常见误解是以为 composer config 命令会触发解密逻辑，其实它只是读取 JSON 并输出原始值（包括明文 token）。真正涉及“解密”的场景，往往来自外部工具链（比如 CI 环境变量注入、Vault 工具预处理 auth.json 文件），而非 Composer 自身机制。
auth.json 中 private-key 的实际加载路径与格式要求
当使用 SSH 私钥认证（例如访问私有 Git 仓库）时，Composer 会把 auth.json 中 private-key 字段的值当作字符串直接写入临时文件，再交由 git 调用。这意味着：
- 该字段必须是完整 PEM 格式私钥内容（含
-----BEGIN RSA PRIVATE KEY-----和换行符），不能是路径 - 如果私钥带密码，Composer 不支持交互式输入，会导致
git clone失败，错误类似：Permission denied (publickey) - Windows 下换行符为
\r\n可能导致解析失败，建议统一用\n - 字段名必须严格为
private-key，不是ssh-private-key或其他变体
GitHub Token 在 auth.json 中如何生效及权限陷阱
GitHub 的 Personal Access Token（PAT）通过 auth.json 的 github-oauth 或通用 http-basic 方式注入，但行为差异很大：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
github-oauth是专用字段，只用于 GitHub API 请求（如获取私有包元数据），不参与git clone - 若仓库 URL 是
https://github.com/...，Composer 默认走 HTTPS 协议拉取源码，此时需要http-basic配置或环境变量GITHUB_TOKEN，否则会因 401 拒绝访问 - PAT 必须至少有
read:packages权限（私有包）或repo（私有仓库），仅public_repo不够 - Token 明文写在
auth.json后，会被所有能读该文件的进程看到，包括 IDE、shell 历史、备份脚本
为什么别在 auth.json 里硬编码敏感信息
根本问题不在“解密机制”，而在于 auth.json 默认权限是 644（可被同服务器其他用户读取），且 Composer 不校验文件所有权或 SELinux 上下文。更现实的风险点：
- CI 构建缓存中残留
auth.json，可能被后续任务复用或泄露 -
composer dump-autoload --optimize不影响 auth.json，但某些插件（如hirak/prestissimo）会缓存凭证，重启后仍生效 - PHP 进程崩溃时，内存 dump 可能包含
auth.json加载后的 token 字符串 - 用
composer config --global写入全局配置，等于把凭证铺到整个系统，比项目级更危险
真要隔离敏感凭据，优先用环境变量（COMPOSER_AUTH）或 CI 平台 secret 注入，而不是依赖不存在的“本地解密”流程。
