auth.json不能提交到Git仓库，因其存储GitHub等私有包的访问凭据，泄露会导致代码窃取、恶意包发布及CI环境渗透；必须加入.gitignore并用COMPOSER_AUTH环境变量替代。
为什么auth.json不能提交到 Git 仓库
因为auth.json里存的是私有包（如 GitHub、GitLab、私有 Packagist）的访问凭据，比如 github-oauth token 或 http-basic 用户名密码。一旦泄露，攻击者可拉取私有代码、伪造包发布、甚至反向渗透你的 CI 环境。
常见错误现象：git add . 后发现 auth.json 被一并提交；CI 日志里意外打印出 token；团队成员本地 composer install 失败后直接把个人 auth.json 提交“修复问题”。
- 默认位置是项目根目录下的
auth.json，但 Composer 也会读取全局路径（如~/.composer/auth.json），后者更危险——一个泄露就影响所有项目 - Git 不会自动忽略它，必须手动加进
.gitignore；且已有历史记录的需用git rm --cached auth.json清除跟踪 - 某些 IDE（如 PHPStorm）在“重新加载 Composer 依赖”时可能自动生成
auth.json到项目目录，需检查设置是否启用了“store credentials in project”
用 COMPOSER_AUTH 环境变量替代文件
这是最干净的方案：不生成 auth.json 文件，靠环境变量注入凭据，天然规避文件泄露风险。
使用场景：CI/CD（GitHub Actions、GitLab CI）、Docker 构建、生产部署脚本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 值必须是合法 JSON 字符串，例如：
COMPOSER_AUTH='{"github-oauth": {"github.com": "xxx-token"}}' - 在 GitHub Actions 中写成：
env:<br> COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH }}，其中secrets.COMPOSER_AUTH是预设的加密 secret - Dockerfile 中避免
COPY auth.json，改用ENV COMPOSER_AUTH=...（注意：仅限构建阶段安全；若运行时需要，应通过--env注入） - 本地开发慎用该方式——容易误把 token 硬编码进 shell 配置，建议仍用全局
auth.json+gitignore保护
区分开发与生产环境的凭据管理
开发环境常用个人 token，生产环境该用最小权限专用 token。混用会导致权限爆炸或泄露面扩大。
关键点在于：Composer 不支持按环境自动切换 auth.json，得靠外部控制。
- CI 中优先用
COMPOSER_AUTH，并为每个项目创建独立的只读 token（GitHub → Settings → Developer settings → Personal access tokens） - 若必须用文件（如老旧部署流程），把
auth.json放在项目外（如/etc/composer/auth.json），再用COMPOSER_HOME指向该路径，确保它不在项目 Git 范围内 - 禁止在
composer.json的config段写死凭据，config只能设路径或开关，不能存敏感数据 - 定期轮换 token，尤其当成员离职或设备丢失时；GitHub 支持查看 token 最后使用时间，可辅助审计
检查与验证是否已暴露
别假设“没人会看我的仓库”，自动化扫描和人工复查都得做。
- 用
git log --all -p --grep="auth.json" --name-only查是否曾提交过 - 执行
git grep -n "github.com.*[a-zA-Z0-9]\{30,\}"扫描疑似长 token 字符串（GitHub token 通常以ghp_或github_pat_开头） - 在 GitHub 仓库 Settings → Security & analysis → Secret scanning 中开启自动检测（对 public repo 免费，private 需 GitHub Advanced Security）
- 如果已泄露，立刻废掉对应 token，并用
git filter-repo --invert-paths --path auth.json彻底从历史中删除（需强制推送，通知协作者重置本地分支）
真正难防的不是明文文件，而是开发者把 token 写进注释、.env 示例、或调试日志里；每次 composer update 前确认当前工作区没残留敏感输出，比任何配置都管用。
