项目级配置是唯一跨环境一致的方案，需将repositories设为数组，首项{"packagist.org": false}，次项为带末尾/的镜像URL；改后必须删除vendor、composer.lock及缓存，再执行composer install。
多环境部署中 Composer 镜像源配置不一致，根本不是“配了没生效”，而是不同环境读取的配置层级和路径压根不同——你本地终端配的 composer config -g，CI 跑的是 runner 用户，宝塔用的是 www 用户，Docker 容器甚至没有 ~/.composer 目录。结果就是同一份代码，在五台机器上走五个源。
为什么 composer config -g 在 CI/宝塔/Docker 里基本等于没配
这条命令写的是当前用户的 ~/.composer/config.json，但：
- GitHub Actions 默认用
runner用户运行，/home/runner/.composer/config.json是空的 - 宝塔面板执行 PHP 命令时以
www用户身份运行，它读的是/home/www/.composer/config.json，不是你的/root/.composer - Docker 构建时基础镜像（如
php:8.2-cli）通常没初始化~/.composer，composer config -g静默失败，不报错也不写入 - 即使你用
sudo composer config -g写进了/root/.composer/config.json，PHP-FPM 进程仍以www-data身份运行，完全加载不到
验证方式：在目标环境直接运行 composer config -g repo.packagist，输出为空、null 或报 Key not found，就说明没生效。
项目级配置怎么写才真正跨环境一致
把镜像声明写进 composer.json 是唯一能绕过用户路径差异的方式，但它必须满足三个硬性结构要求：
-
"repositories"必须是数组（[]），不能是对象（{}）；写成"repositories": {}会直接禁用所有默认源，且不加载你配的镜像 - 首项必须是
{"packagist.org": false}——这是显式关闭官方兜底的开关，必须独立成项，不能合并进其他仓库定义里 - 第二项才是镜像源：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，注意url末尾必须带/，否则请求变成/composerpackages.json导致 404
正确示例（直接编辑 composer.json）：
"repositories": [
{"packagist.org": false},
{"type": "composer", "url": "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.lock里记录的是旧的dist.url，比如https://api.github.com/，不删它，composer install就永远按旧地址下载 -
vendor/目录残留旧包，Composer 可能跳过重装，导致依赖解析仍基于旧元数据 - 本地
packages.json缓存未刷新，Composer 默认复用 15 分钟内未过期的~/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json
必须执行三步：
rm -rf vendor/ composer.lock-
composer clear-cache（清 dist 包） -
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer（手动删元数据缓存） - 再跑
composer install（不是update）
验证是否真走镜像：加 -vvv 参数，composer install -vvv 2>&1 | grep "Downloading"，确认日志里出现的是 mirrors.aliyun.com，不是 api.packagist.org。
生产环境必须加 --no-dev 和 --optimize-autoloader
镜像只加速下载，不改变安装逻辑。生产环境若漏掉这两个参数：
-
--no-dev缺失 →phpunit、symfony/debug-bundle全部装进线上vendor/，体积暴涨、安全扫描告警、运行时报Call to undefined function xdebug_is_enabled() -
--optimize-autoloader缺失 → 自动加载慢 3–5 倍，尤其 Laravel/Symfony 项目启动明显卡顿
Dockerfile 中应写死：
RUN composer install --no-dev --optimize-autoloader
GitHub Actions 或宝塔部署脚本里也必须显式带上，不能依赖默认行为。
最易被忽略的一点：项目级 repositories 数组一旦存在，全局 config -g 就彻底失效，连 fallback 都不会触发——这不是 bug，是 Composer 的明确设计。别指望“两边都配”能叠加生效，要么全用项目级，要么确保所有环境用户上下文绝对一致（现实中几乎不可能）。
