composer日志明文泄露token因http请求url拼接凭据并默认输出，--no-interaction和composer_disable_tty无法抑制；有效方案是在进程外用sed过滤stderr（如s/:[^@]*@/@/g）或结合临时composer_home与环境变量注入，github actions中需额外加过滤层而非依赖mask-secrets。
Composer日志里为什么总出现明文token？
因为composer install或composer update在连接私有仓库（如GitLab、GitHub Packages、自建Satis）时，会把认证凭据拼进HTTP请求URL里，而Composer默认把完整请求URL打到stderr/stdout——https://token:xxx@gitlab.example.com这种形式直接暴露在构建日志中。
用COMPOSER_DISABLE_TTY + --no-interaction能屏蔽吗？
不能。这两个参数只影响交互式提示和TTY检测，不影响HTTP请求日志输出逻辑。即使加了--no-interaction，只要COMPOSER_AUTH或auth.json里有token，它照样出现在composer diagnose或网络调试日志里。
-
COMPOSER_AUTH环境变量值会被原样解析，token不脱敏 -
auth.json文件中的http-basic或github-oauth字段内容也会被用于构造带凭据的URL - Composer 2.5+ 引入了
COMPOSER_NO_INTERACTION，但依然不处理日志过滤
真正有效的日志过滤方案
必须在Composer进程外部做日志流处理，而不是依赖Composer内置配置。CI/CD中推荐以下两种方式：
- 用
sed或perl实时过滤stderr：composer install 2> >(sed 's/:[^@]*@/@/g' >&2) 2>&1
这个正则会把https://token:abc123@gitlab.com变成https://token:@gitlab.com，保留协议和域名结构，又抹掉敏感段 - 用
COMPOSER_HOME指向临时目录，配合空auth.json+ 环境变量注入凭据：COMPOSER_HOME=$(mktemp -d) composer config http-basic.repo.example.com user "$TOKEN" --global
再执行composer install，此时凭据存在临时auth.json里，但日志仍含URL——所以仍需配合上面的sed过滤 - GitHub Actions中可直接用
mask-secrets（但仅对set-output和echo ::add-mask::生效），对Composer原始stderr无效，必须额外加过滤层
为什么不用--verbose或--debug开关？
开启--verbose或--debug反而会让token更显眼——它会打印完整cURL命令、HTTP头和重定向跳转URL，其中包含多次重复的凭据片段。越想排查问题，越容易把token打满日志。
真正要做的，是在CI runner启动命令层就套一层过滤，别指望Composer自己“懂事”。日志里留一个@占位符比留一串base64或hex token安全得多，也足够定位仓库地址问题。
