composer config -g不能用于团队同步，因其仅写入当前用户~/.composer/config.json，而CI/CD、宝塔www用户、Docker runner等环境均不读该路径；项目级需在composer.json中以{"packagist.org": false}为首项声明repositories数组，并删除vendor与composer.lock后执行composer install。
为什么composer config -g不能当团队同步方案
它只写进当前用户的~/.composer/config.json，而 CI/CD 容器、宝塔的 www 用户、Docker 中的 runner 用户，压根不读这个文件。你本地配好了，GitHub Actions 里照样卡在 Loading composer repositories。更隐蔽的是：有人用 sudo composer config -g 写进了 root 配置，但 PHP 进程以 www-data 身份运行，镜像完全不生效。
repositories 数组必须首位禁用 packagist.org
Composer 2.2+ 不再把 repositories 当作元数据源列表，而是硬编码走 repo.packagist.org。想让它真走镜像，必须在 composer.json 里显式切断官方回退路径：
- 第一项必须是独立对象：
{"packagist.org": false}，不能合并到下一项里 - 第二项起才是镜像和私有源，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - URL 末尾必须带
/，少一个斜杠会拼成/composerpackages.json导致 404 - 已有 Git 私有包（
"type": "vcs"）可继续放在后面，顺序不影响解析
换镜像前必须删 vendor/ 和 composer.lock
镜像只缓存元数据（packages.json），不托管实际包文件。composer.lock 里记录的 dist.url 如果还是 https://api.github.com/，Composer 就绕过镜像直连 GitHub——你看到的“卡在 Downloading”其实是没走镜像。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
rm -rf vendor/ composer.lock是硬性前置步骤 - 再跑
composer install --no-cache，强制拉取镜像站的元数据并生成带镜像域名的新dist.url - 保留旧
composer.lock必然失败：哈希值和镜像返回的元数据不匹配
CI/CD 和 Docker 环境里怎么确保镜像生效
靠人工在每台机器上敲命令不现实。关键点在于让配置可版本化、可复现、不依赖用户家目录：
- 把镜像配置写进
composer.json并提交 Git，这是唯一能被所有环境一致读取的方式 - CI 脚本（如
.github/workflows/ci.yml）开头加一步：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，避免因 runner 干净环境导致 fallback - Dockerfile 中，在
composer install前插入：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否真走镜像：看
composer install日志里Downloading行的域名，或直接curl -I https://mirrors.aliyun.com/composer/p2/symfony/console/6.4.0.json测响应
最常被忽略的是：镜像不是全量实时同步，而是按需拉取。你要装的某个 provider-*.json 文件如果镜像还没缓存，就会触发反向拉取，这时延迟和失败风险最高——别等报错才去查，提前用 curl 验证目标 URL 是否存在。
