auth.json 不经镜像，仅本地读取且不可通过 git 同步；应存于全局路径并设权限600，跨设备共享须用环境变量或密码管理器，禁用直接拷贝或提交。
镜像源本身不处理 auth.json，加密与共享是两件独立的事：auth.json 从不经过镜像，它只在本地读取；跨设备共享必须绕过 Git，不能靠镜像同步。
auth.json 为什么不能走 Composer 镜像
Composer 镜像（如阿里云、腾讯云）只代理 packages.json 和元数据请求，auth.json 是纯本地文件，Composer 在安装前就已读取完毕，根本不会发 HTTP 请求去“拉取”它。所以无论你配了多少镜像，auth.json 的内容、位置、权限都完全不受影响——也意味着镜像无法帮你加密或分发它。
- 镜像只加速元数据下载，不参与认证流程
-
auth.json加载发生在composer install最初阶段，早于任何远程仓库交互 - 试图把
auth.json提交到 Git 再通过镜像“同步”，等于把 token 直接暴露给所有人
如何安全加密 auth.json 文件本身
直接加密 auth.json 文件不是 Composer 的设计目标，但你可以用 git-crypt 在 Git 层做透明加解密，前提是它不被误提交。关键动作不是加密文件，而是控制它“在哪”和“怎么进 Git”：
- 先确保
auth.json不在项目根目录——删掉./auth.json，改用全局路径~/.composer/auth.json（Linux/macOS）或%APPDATA%\Composer\auth.json（Windows） - 如果团队真需要共享某套凭据（比如 CI 公共 token），不要放
auth.json，改用环境变量COMPOSER_AUTH，并在 CI 中通过 secret 注入 - 若必须进 Git（极少见），重命名成
composer.auth.json，加进.gitattributes：composer.auth.json filter=git-crypt diff=git-crypt，再git-crypt init初始化密钥 - 切勿对
~/.composer/auth.json做 git-crypt —— 它本就不该进 Git，且用户主目录通常不在版本控制中
跨设备共享凭据的可行路径
跨设备 ≠ 跨 Git，而是“让不同机器获得等效访问权”。硬拷贝 auth.json 或同步 home 目录风险极高，应优先走可审计、可撤销的机制：
- 开发机之间：用
composer config -g逐台写入，配合密码管理器复制 token，避免明文粘贴到终端历史 - CI/CD 环境：用平台 secret（如 GitHub Actions 的
secrets.COMPOSER_AUTH）注入环境变量，Docker 构建时用--env COMPOSER_AUTH=...，而非 COPY 文件 - 团队共用私仓凭据：由管理员生成专用只读 token，通过内部文档分发 + 定期轮换，不绑定个人账号
- 绝对禁止：rsync
~/.composer/auth.json到另一台机器、或把该文件打包进 dotfiles 仓库
真正容易被忽略的是权限与上下文隔离：~/.composer/auth.json 在 Linux/macOS 下权限必须为 600，否则 Composer 静默跳过；而 Windows 上若用错路径（比如写了 C:\Users\Name\.composer\auth.json 而非 %APPDATA%\Composer\auth.json），文件根本不会被加载——这些细节比“怎么加密”更常导致认证失败。
