Composer install卡在Downloading https://packagist.org/packages.json即失败，因默认源在国内不可靠；必须严格配置repo.packagist键（单数）、type为composer、URL以https://开头且结尾带/，并按运行用户（如www-data）或项目级配置生效，否则静默回退至官方源。
热修复补丁发布前，composer install 卡在 Downloading https://packagist.org/packages.json 就等于失败——这不是 Composer 慢，是默认源在国内不可靠。必须让线上机器「开箱即用」走国内镜像，且对所有运行用户（如 www-data、nginx）生效。
为什么 composer config -g repo.packagist 总是不生效
它不是“改个 URL 就完事”，而是三要素缺一不可，漏掉任意一个，Composer 2.2+ 会静默 fallback 到 https://packagist.org，不报错、不提示、不警告：
-
repo.packagist必须是单数键名，写成repos.packagist（多 s）或packagist（少 repo.）都会被忽略 - 第二个参数必须显式写
composer，这是 type 声明，不是可选注释 - URL 必须以
https://开头、以/结尾，例如https://mirrors.aliyun.com/composer/；少斜杠会拼出/composerpackages.json导致 404，然后退回到官方源
验证是否真生效，只看这一条命令输出：composer config -g repo.packagist
必须返回完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、"https://packagist.org" 或报 Key not found，说明配置失败。
线上机器必须按运行用户配，不能只配 root
你在终端用 root 配了全局镜像，但 PHP-FPM、Nginx 或宝塔后台实际是以 www-data、nginx 等非 root 用户启动的，它们读不到 root 的 ~/.composer/config.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 对单用户环境：用
sudo -u www-data composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 对 ECS（阿里云）：优先用内网地址，
http://mirrors.cloud.aliyuncs.com/composer/（VPC）或http://mirrors.aliyuncs.com/composer/（经典网络），延迟压到 10ms 内 - Windows 下注意权限：
%APPDATA%\Composer\config.json可能被系统锁定，手动编辑后需确认文件可写
项目级配置比全局更稳，尤其适合 CI/CD 和容器部署
CI 脚本、Docker 构建、宝塔部署常以不同用户执行，全局配置极易失效。项目级配置写进 composer.json，Git 可追踪、所有人行为一致。
- 进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不带-g） - 该命令只向
composer.json的repositories对象里追加"packagist"字段——前提是原repositories是对象{}，不是数组[]；若已是数组，需先手动改成对象 - 别手写
"packagist.org": false，这会彻底关掉默认源，镜像临时不可用时composer install直接失败 - 换源后必须删掉
vendor和composer.lock，再跑composer install --no-dev；否则composer.lock里仍存着旧 dist URL，可能因路径不匹配或校验失败卡住
镜像和代理不能共存，且镜像不解决依赖解析卡顿
一旦设了 repo.packagist 镜像 URL，Composer 就直接连该地址，完全绕过 http-proxy/https-proxy 配置。两者并存反而可能引发 TLS 握手失败或 DNS 解析异常。
- 代理仅用于绕过防火墙，不是缓存机制；若真要用代理，必须同时设置
http-proxy和https-proxy，且地址前缀必须是http:// -
composer install卡在Resolving dependencies？和镜像无关。问题大概率出在：composer.json中 PHP 版本约束太宽、含大量dev-分支依赖、或require-dev里塞了废弃插件（如fxp/composer-asset-plugin）
最易被忽略的一点：Docker 多阶段构建中，COPY . /app 放在 COPY composer.json composer.lock ./ 之前，或中间插入任何 RUN 指令，都会让 vendor 缓存链彻底断裂——热修复时本该秒级完成的构建，可能拉长到 3 分钟以上。
