Jenkins中composer config -g无效，因agent每次构建均为全新环境且项目级repositories会完全屏蔽全局配置；正确做法是Pipeline中动态探测镜像可用性，写入项目级composer.json的repositories首项，清理vendor与lock文件，并保留私有源。
为什么Jenkins里composer config写不进实际运行环境
因为Jenkins agent每次启动都是干净容器，composer config -g写入的是当前shell进程下的~/.composer/config.json，但这个路径在下次构建时可能被重置或根本不在挂载卷里。更麻烦的是：只要项目根目录存在composer.json且含"repositories"字段，全局配置就会被完全忽略。
- 确认执行用户：
whoami或看Jenkins日志里的UID，别用sudo composer config -g往root家目录写 - 不要依赖
-g，改用项目级配置：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾必须有/） - 验证是否生效：
composer config -g repo.packagist输出应为完整JSON，不是空或packagist.org
动态探测镜像源并 fallback 到 packagist.org
Jenkins Pipeline 不能硬编码镜像地址，得每次构建前实测可用性——国内镜像偶尔抽风，直接连不上会导致整个构建卡死。
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检查HTTP状态码 - 返回非200时，改设为
https://packagist.org，并确保composer.json中"packagist.org": false被移除或设为true - 执行前删掉
vendor/和composer.lock，否则Composer仍会沿用旧lock里的dist URL，镜像配置无效
私有仓库和中文镜像共存的写法
直接composer config repo.packagist会清空整个repositories数组，导致私有Git包解析失败。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 手动编辑
composer.json，把镜像源作为repositories数组第一个元素 - 私有源跟在后面，例如：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}、{"type":"vcs","url":"https://git.internal/pkg"} - 显式保留
packagist.org兜底项：{"packagist.org": true}，避免私有源失效时彻底断连
CI脚本里最容易被忽略的三个“伪中文”坑
报错信息里出现乱码或invalid argument '——no-dev'，往往不是参数写成中文，而是不可见字符混入命令行。
- 复制粘贴自微信/QQ/Notion的命令，常带全角空格或零宽空格（U+200B），用
cat -A your_script.sh能看见M-BM-这类标记 - Git提交时启用了
core.autocrlf，Windows换行符\r\n被某些Alpine shell拒绝解析 - 编辑器保存为UTF-8 with BOM，BOM头会让
#!/usr/bin/env bash变成非法指令，脚本第一行就静默退出
真正要配的从来不是“中文”，是环境干净度、参数组合完整性、以及镜像配置的持久化路径——Jenkins里没“中文镜像”这回事，只有你写的那行composer config到底有没有落到对的用户、对的文件、对的时机上。
