生产服务器上必须用项目级配置（composer config repo.packagist composer https://mirrors.aliyun.com/composer/）替代全局配置，因-g写入用户目录而Web进程无权读取，静默回退至packagist.org；需确保repositories为对象、URL末尾带/、删净vendor和composer.lock后执行install --no-dev --optimize-autoloader --classmap-authoritative并验证autoload_classmap.php。
生产服务器上配 Composer 镜像源，不写对三个硬性条件就等于没配——它不会报错，只会静默 fallback 到 packagist.org，拖慢部署、耗光带宽、甚至触发超时。
composer config -g repo.packagist 在服务器上基本无效
你在终端里用 root 或 deploy 用户执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，composer config -g repo.packagist 也输出了正确 JSON，但 PHP-FPM、systemd service 或 CI runner 启动的 composer install 依然走官方源。
原因很直接：-g 写的是当前用户的 ~/.composer/config.json，而 Web 服务进程（如 www-data、nginx、runner）根本读不到这个路径，权限和家目录都不匹配。
更糟的是，有些 Docker 基础镜像甚至没创建 /root/.composer 目录，config -g 看似成功，实则连文件都没写进去。
- 验证方式：切换到实际运行用户（比如
sudo -u www-data bash），再执行composer config -g repo.packagist—— 很可能返回空或报错 - 系统级配置（
/etc/composer/config.json）理论上可行，但要求路径严格、权限 755、结构是对象而非数组，且多数发行版默认不建该目录，维护成本高 - 结论：别在服务器上依赖
-g，它不是“不推荐”，而是“不可靠”
项目级配置才是生产部署的唯一可靠方案
进项目根目录后运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意没有 -g），这条命令会修改 composer.json 的 repositories 字段，把镜像源固化进代码里。
它生效的前提是：repositories 在 composer.json 中是对象（{}）而非数组（[]）。如果已经是数组，命令会失败，需先手动改成空对象。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 优先级最高：项目级配置永远覆盖全局和默认源，不受执行用户影响
- CI/CD 友好：Git 提交后，所有环境（GitHub Actions、GitLab CI、阿里云效）都自动走镜像，无需额外脚本
- 内网优化可叠加：ECS 用户应改用内网地址
http://mirrors.cloud.aliyuncs.com/composer/（仅限阿里云 VPC），延迟压到 10ms 内 - 必须删干净再重装：改完立刻
rm -rf vendor composer.lock，再跑composer install --no-dev --optimize-autoloader --classmap-authoritative
换源后仍卡在 “Loading composer repositories” 怎么快速定位
这不是镜像慢，而是 Composer 还在读旧缓存或旧 composer.lock 里记录的官方地址。日志里只要出现 packagist.org，说明镜像根本没走通。
排查顺序必须严格：
- 先清缓存：
composer clear-cache - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s/q vendor && del composer.lock） - 加详细日志重装：
composer install -vvv 2>&1 | grep -i "loading\|downloading" - 观察输出中是否含
mirrors.aliyun.com或mirrors.cloud.aliyuncs.com；若仍有packagist.org，回头检查composer.json的repositories结构是否异常，或 URL 少了末尾/
特别注意：composer update 不解决这个问题——它只更新依赖版本，不刷新元数据源地址；必须用 install 重建整个锁文件。
生产环境必须搭配 classmap 权威加载才真正提速
只换镜像源，不加 --no-dev --optimize-autoloader --classmap-authoritative，自动加载性能几乎没变化。镜像只加速下载，真正的性能瓶颈在运行时类加载。
这三个参数必须同时出现：
-
--no-dev：避免把测试类、Mock 类扫进 classmap，污染映射表 -
--optimize-autoloader：触发完整 classmap 构建（含 PSR-4、classmap、files 等） -
--classmap-authoritative：关闭 fallback 查找，省掉大量file_exists()和目录遍历
验证是否生效：vendor/composer/autoload_classmap.php 文件必须存在、大小 >100KB、内容包含你项目里绝大多数类名。否则就是白配——镜像再快，autoload_static.php 里没映射，照样慢。
