CI中composer config -g repo.packagist无效，因CI用户读不到本地全局配置，必须在CI脚本中显式执行该命令或改用项目级repositories配置，并删vendor和composer.lock后重装。
composer config -g repo.packagist 命令在 CI 中根本不会生效
CI 环境（GitHub Actions、GitLab Runner、Jenkins）默认以独立用户（如 runner、jenkins）运行，它读不到你本地 ~/.composer/config.json。哪怕你在本地执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，CI 里依然走 https://packagist.org。
常见表现：CI 日志里 Downloading 的域名仍是 packagist.org，或直接超时失败。
- 必须在 CI 脚本中显式执行全局配置命令，且确保该命令在
composer install之前运行 - GitHub Actions 示例（放在
steps中）：run: composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 若使用自托管 runner，还需确认 PHP CLI 用户有写入
~/.composer/的权限；否则加--no-interaction并配合chown预处理
项目级 repositories 配置才是 CI 友好的方案
把镜像写进 composer.json 的 repositories 字段，CI 拉代码后直接生效，不依赖任何环境预设。
进项目根目录执行这条命令即可（注意去掉 -g）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 该命令会自动在
composer.json顶层添加"repositories": {"packagist": {...}}，不覆盖已有私有源 - 如果项目已有
"repositories": []（数组），命令会报错；需先手动改为"repositories": {}再重试 - 改完必须删掉
vendor/和composer.lock，再跑composer install—— 否则旧lock文件仍指向官方源的包 hash
CI 中 composer install 卡在 Resolving dependencies？别怪镜像
镜像只影响下载阶段（Downloading），不影响依赖解析（Resolving dependencies）。CI 里卡在这里，99% 是 composer.json 写法问题。
-
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束会让 Composer 尝试数百种版本组合 -
require-dev里塞了未锁定的"phpunit/phpunit": "^10.0"或"friendsofphp/php-cs-fixer": "dev-main"，极大拖慢求解器 - 解决方案不是换镜像，而是收紧约束：
"php": "^8.1"、"phpunit/phpunit": "10.5.1"、删掉所有dev-分支依赖
宝塔、Docker、code-server 环境下镜像配置失效的真正原因
这些环境常禁用 PHP 函数（如 proc_open、putenv），导致 Composer 启动失败，根本没机会走到镜像逻辑。
典型现象：composer install 报 proc_open(): fork failed 或直接无输出。
- 宝塔：进「PHP 管理」→ 对应版本 → 「禁用函数」页签 → 删除
proc_open、putenv、pcntl_signal - Docker：在
Dockerfile中确保php -m | grep -E "openssl|tokenizer"有输出，且php.ini未禁用关键函数 - code-server：确认其底层容器或宿主机的 PHP CLI 环境与终端一致，避免出现
php -v正常但composer -v报错
