composer config -g repo.packagist 命令必须严格满足三要素：键名 repo.packagist（单数）、type 值显式为 composer、URL 为 HTTPS 且末尾带 /，缺一则静默失效；验证需执行 composer config -g repo.packagist 输出完整 JSON，空或 packagist.org 表示未生效。
换镜像源不是“试试看”，而是必须严格按格式执行，否则 composer install 仍会卡在 Downloading https://packagist.org/... —— 这不是你网速差，是配置根本没生效。
composer config -g repo.packagist 命令为什么总不生效
这条命令写错任意一处，都会静默失败：不报错、不提示、install 照样超时。
-
repo.packagist必须是单数，写成repos.packagist（多一个 s）就完全无效 - 必须显式带上
composer类型标识，完整写法是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；漏掉中间的composer，Composer 2.x 会 fallback 回官方源 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer（缺斜杠）会导致请求拼成/composerpackages.json，直接返回 404 - 验证是否真生效：运行
composer config -g repo.packagist，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}或类似结构；空、null或仍是packagist.org，说明没写对
宝塔/CI 环境下镜像不生效的权限与环境问题
宝塔后台任务、Docker 容器或 Jenkins 构建脚本，往往以 www 或非 root 用户身份执行，而 composer config -g 默认写入的是当前 shell 用户的 ~/.composer/config.json，其他用户根本读不到。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先确认执行用户：在终端运行
whoami，再查该用户的家目录下是否存在.composer/config.json - 若需让
www用户也走镜像，切换用户再配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本开头必须固化
COMPOSER_HOME：加一行export COMPOSER_HOME=/tmp/composer，再跑composer config -g，否则容器重启后配置丢失 - 国内多数镜像站 IPv6 支持不完整，CI 环境常默认启用 IPv6，导致隐性延迟叠加；强制走 IPv4：
COMPOSER_IPV4=1 composer install（Windows 下设系统环境变量COMPOSER_IPV4 = 1，值是字符串1，不是布尔）
换源后仍卡在 Resolving dependencies 或 Generating autoload files
镜像源只加速包下载（Downloading 阶段），对依赖解析和自动加载生成完全无效。这两阶段卡住，和网络无关。
-
Resolving dependencies卡顿，大概率是composer.json中 PHP 版本约束过宽，例如"php": "^7.4 || ^8.0"，让 Composer 尝试匹配大量版本组合 -
Generating autoload files后无响应，99% 是 I/O 阻塞（如 NFS 挂载、低配 VM 磁盘慢），不是超时问题；可临时改用composer install --no-autoloader验证 - 注意：
process-timeout控制整个命令生命周期，默认 300 秒；但它超过 7200 秒会被 Composer 主动忽略并回退到 300 秒——这是硬编码限制，设再大也没用 -
http-timeout才是唯一影响Downloading阶段的参数，建议设为600：composer config -g http-timeout 600；若共享主机静默忽略该配置，改用环境变量：COMPOSER_HTTP_TIMEOUT=600 composer install
项目里有 prefer-source 或私有 Git 仓库怎么办
镜像源只加速 dist（ZIP/TAR 包），对 source（Git clone）完全无效。只要项目含以下任一情况，Composer 就会 fallback 直连 GitHub/GitLab，触发超时。
- 检查
composer.json是否含"prefer-source": true - 检查是否用了
git@类地址（如"repo": "git@github.com:xxx/yyy.git"）或硬编码了repositories - 若有私有仓库，别直接替换
packagist.org，应设为代理：composer config -g repos.aliyun composer https://mirrors.aliyun.com/composer/，再禁用默认源：composer config -g repos.packagist false - 清旧缓存必不可少：
composer clear-cache；看到两行Clearing cache (cache-dir):和Clearing cache (cache-vcs):才算完成
真正容易被忽略的点是：换源 ≠ 解决所有卡顿。Downloading 阶段靠镜像 + http-timeout，Resolving 阶段靠收紧版本约束，autoload 阶段靠排查 I/O。三者混在一起报“超时”，得先分清卡在哪一步，再动哪根弦。
