auth.json不能提交到Git，因其明文存储用户名、密码或token，一旦推送到远程仓库即等同于公开公司私有包访问权限；即使添加.gitignore也常因误操作导致泄露，历史提交需用git filter-repo彻底清理。
auth.json 文件为什么不能直接提交到 Git
因为 auth.json 里明文存着用户名和密码（或 token），一旦被推到远程仓库，所有有权限读代码的人都能拿到凭证，等同于把公司私有包的门钥匙贴在 GitHub 首页。即使加了 .gitignore，也常有人误操作漏忽略、或历史提交里残留过凭证。
- 检查是否已忽略：
git check-ignore -v auth.json，没输出就说明没生效 - 若已误提交，必须用
git filter-repo彻底从历史中删干净，仅删文件本身不够 - 全局
auth.json（~/.composer/auth.json）同样不能共享——它影响所有项目，泄露后危害更大
COMPOSER_AUTH 环境变量怎么用才安全
这是 CI/CD 和容器部署中最推荐的方式：凭证不落地、不进版本控制、生命周期与任务绑定。但直接写死在脚本里或 shell 命令行里依然危险——比如 export COMPOSER_AUTH='{"http-basic":...}' 会留在 bash history，且可能被 ps 看到。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitLab CI 中优先用预置变量：
$CI_JOB_TOKEN，配合auth.json模板动态生成，不暴露原始值 - GitHub Actions 中用
secrets.GITHUB_TOKEN或自定义 secret，通过${{ secrets.MY_TOKEN }}注入，绝不在日志中 echo - 本地开发慎用：环境变量易被子进程继承，建议只在 CI 脚本中临时设置，不用 export 全局
GitHub/GitLab OAuth token 的权限怎么最小化
token 权限越大，泄露后攻击面越广。别图省事勾选 admin:org 或 user，很多项目只需要读代码权限就能跑 composer install。
- GitHub token 至少勾选
repo（私有库读取），如用 GitHub Packages 再加read:packages - GitLab token 只需
read_repository，不要开api或write_repository - 细粒度 token（GitHub 新版）比 classic token 更可控，能限定到具体仓库、甚至只允许 package read
- token 生效后立即测试：
composer diagnose看是否报401 Unauthorized，避免权限不足导致构建失败
SSH 密钥替代 HTTP token 的实操要点
对纯 Git 托管的私有包（不是 Packagist 类型仓库），SSH 是更干净的方案：无需 token 管理、无 API 速率限制、凭证天然隔离。
- 生成专用密钥：
ssh-keygen -t ed25519 -C "deploy@myproject" -f ~/.ssh/id_rsa_composer_deploy，别用默认id_rsa - 公钥加到 Git 服务的「Deploy Keys」（不是用户 SSH Keys），并勾选「Write access」关闭——只读足够
- CI 中注入私钥时，用
ssh-add <(echo "${SSH_PRIVATE_KEY}")方式，避免写临时文件；记得chmod 700 ~/.ssh - 确保
composer.json里的仓库 URL 是git@github.com:org/repo.git格式，不是 HTTPS
