卡在“loading composer repositories”是镜像未生效所致，因url缺末尾斜杠、键名误写为repos.packagist或漏掉type值，导致composer静默回退至packagist.org；应运行composer config -g repo.packagist验证输出是否为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
为什么配了镜像 still 卡在 “Loading composer repositories”
这不是镜像没生效，而是 Composer 正在解析 composer.json 中的依赖树——这个阶段不走镜像，只走元数据源（packages.json）。如果镜像 URL 少了末尾斜杠、键名写成 repos.packagist 或漏掉 composer 这个 type 值，Composer 会静默 fallback 到 https://packagist.org，然后卡在 TLS 握手或 DNS 解析上。
验证是否真走镜像，别看命令输出，直接运行：
composer config -g repo.packagist
✅ 正确返回必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
❌ 返回空、null、纯字符串 "https://packagist.org"，说明配置根本没写进去。
- Windows 用户改完没重启终端，PHP 进程读不到新配置
- Linux/macOS 下用
sudo composer config -g ...，实际写进的是 root 用户的~/.composer/config.json，但项目构建可能用的是普通用户 - 项目级
composer.json中存在"repositories"字段，会无警告覆盖全局配置
临时切镜像验证 Laminas 包是否可装
Laminas 组件发布后，国内镜像通常有 5–10 分钟同步延迟。若刚发新版（如 mezzio/mezzio-skeleton v4.8.0），阿里云/腾讯云镜像还没同步，Could not find package 就不是配置问题，而是源没数据。
此时用 --repository 强制单次走指定源，绕过所有配置：
composer create-project mezzio/mezzio-skeleton myapp --repository=https://mirrors.tuna.tsinghua.edu.cn/composer/
注意：--repository-url 和 --mirror 是无效参数，Composer 不识别，会静默忽略。
- 临时命令不改变任何配置，适合 CI 脚本中兜底使用
- 若仍报错
Could not find package，去对应镜像站首页手动访问https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json确认是否已同步 - 不要混用
--repository和项目级repositories，否则依赖解析逻辑会异常
项目级配置比全局更可靠，尤其对 Laminas 多组件组合场景
Laminas 推荐按需引入 laminas-mvc、laminas-router 等独立包，而非单体框架。这种结构下，不同组件可能来自不同源（比如私有模块托管在 GitLab），全局镜像容易误覆盖私有源请求。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
进项目根目录，执行（不带 -g）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动在 composer.json 的 "repositories" 下添加 "packagist" 条目，且不影响已有私有源定义。
- 改完必须运行
composer update --lock，否则composer.lock仍记录旧源地址 - 如果
composer.json原本是"repositories": {}，命令会转为标准对象；若是"repositories": []，则命令失败，需手动编辑 - CI 环境（如 GitHub Actions）默认以 runner 用户执行，它根本读不到你本地的全局配置
换镜像后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速下载环节（Downloading、Fetching package），不加速依赖求解。Laminas 项目若含大量 dev-only 依赖、或 "minimum-stability": "dev"，Composer 需遍历所有版本约束，耗时可能达数分钟。
这时 composer install 停在 Resolving dependencies，不是网络问题，是算法复杂度高。
- 检查
composer.json是否误设"minimum-stability": "dev"，生产环境应设为"stable" - 删掉
vendor/和composer.lock后，加-vvv运行composer install，观察日志里是否反复出现Trying...—— 这是求解器在回溯 - 若用 Mezzio，优先选
PHP-DI容器而非laminas-servicemanager，前者依赖图更扁平，求解更快
真正容易被忽略的点：镜像配置成功 ≠ 安装变快。元数据拉取、依赖求解、ZIP 解压、autoload 生成，每个环节都可能成为瓶颈——而只有第一个环节能靠镜像解决。
