composer config -g repo.packagist 命令常因拼写错误（如repos）、漏写type: composer、URL缺HTTPS或末尾斜杠而静默失效；宝塔中全局配置对www用户无效，推荐项目级配置；镜像仅加速下载，不解决依赖解析慢问题。
直接搭私有 Composer 镜像源不现实，99% 的 PHP 项目根本不需要——你真正需要的，是正确配置已有的可信国内镜像，避开静默失效、安全降级、权限错位这三类高频陷阱。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是命令写错了三个关键点，且 Composer 不报错，只静默忽略：
-
repo.packagist不能写成repos.packagist（多一个 s 就完全无效） - 必须显式写出
composer这个 type 值，漏掉就 fallback 到官方源 - URL 必须用 HTTPS，且末尾带
/，例如https://mirrors.aliyun.com/composer/，缺斜杠会导致路径拼成/composerpackages.json直接 404
验证是否生效，只看这一条命令输出：composer config -g repo.packagist。正确结果应为类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回空、null 或报错，说明没写对。
宝塔面板里全局配置经常“失灵”的真实原因
宝塔后台点击「一键部署」或通过「PHP 管理器」执行的 Composer 命令，往往以 www 用户身份运行，而 composer config -g 默认写的是 /root/.composer/config.json，www 用户根本读不到。
解决方法只有两个：
- 给
www用户单独配：先sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 或者更稳妥：放弃全局配置，改用项目级配置（见下一条）
别信“改完就全站加速”的说法——用户权限链断了，命令再对也没用。
项目级配置为什么比全局更可靠
它把镜像声明直接写进 composer.json 的 repositories 字段，Git 可追踪、CI 可复现、新人拉代码即生效，且优先级高于全局配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
操作只需一步（在项目根目录执行）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
注意：去掉 -g。这条命令会自动合并进现有 repositories 对象，不会覆盖你已有的私有包源（前提是 repositories 当前是 JSON 对象，不是数组）。
换源后首次 composer install 若报 hash 校验失败，删掉 vendor 和 composer.lock 重来即可。
换源后 update 还卡在 Resolving dependencies？那和镜像无关
镜像只加速包文件下载（.zip / .tar），不参与依赖解析。如果你发现 composer update 卡在 Resolving dependencies 几十秒以上，问题一定出在本地环境或 composer.json 写法上：
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0" -
require-dev里塞了大量未锁定版本的工具链 - 用了太多
dev-分支或@dev标签
这时候换任何镜像都没用，得精简约束、锁定版本、拆分 require-dev。
最常被忽略的一点：安全。单纯执行 composer config -g repo.packagist 会完全绕过 packagist.org 的签名验证，一旦镜像被污染，你拉下的就是被篡改的代码。真要兼顾速度与安全，得启用 security.signature true 并确保镜像源同步 signature 元数据——目前阿里云、华为云等主流镜像已支持，但配置方式和普通换源完全不同。
