真正起作用的是镜像是否支持索引分片+composer 2.9.6+客户端协同，阿里云/腾讯云镜像可将packages.json拆分为p/packages-a.json等子文件，避免全量加载元数据；需通过composer install -v观察多条分片请求验证，否则退化为全量加载。
中文镜像本身不降低 Composer 内存占用，真正起作用的是镜像是否支持索引分片 + Composer 客户端是否启用该能力。阿里云/腾讯云镜像在 Composer 2.9.6+ 下可将 packages.json 拆成按前缀划分的子文件（如 p/packages-a.json），避免一次性加载数百万包元数据——这是解决“Loading composer repositories”卡死的唯一有效路径。
确认是否真走分片加载
执行 composer clear-cache 后运行 composer install -v，观察日志：
- ✅ 正确表现：出现多条类似
Loading https://mirrors.aliyun.com/composer/p/packages-a.json的独立请求 - ❌ 失效表现：只看到
Loading https://mirrors.aliyun.com/composer/packages.json——说明退化为全量加载
常见失效原因：
-
composer config -g repos.packagist格式写错，导致 fallback 到默认源（日志中含"url": "https://packagist.org"） - 项目级
composer.json中repositories覆盖了全局配置，但 URL 未指向分片镜像（如仍用https://packagist.phpcomposer.com） - 镜像地址过时（华为云镜像目前仍是全量快照，不支持分片）
php -d memory_limit 必须显式指定
COMPOSER_MEMORY_LIMIT 环境变量对内存溢出几乎无效——它只在 Composer 解析逻辑内部生效，而 packages.json 加载、依赖图构建等重头戏发生在 PHP 底层 memory_limit 被击穿之后。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：直接跑
php -d memory_limit=512M composer install - Windows PowerShell：注意引号，
php "-d" "memory_limit=512M" composer install - CI 环境推荐固定值（如
2G），避免用-1掩盖依赖膨胀问题 - 若
which composer返回/usr/bin/composer，说明是 shell wrapper，必须绕过：php -d memory_limit=512M /path/to/composer.phar install
autoload 注册重复是 Web 环境的隐藏内存杀手
PHP-FPM 或 Swoole 长生命周期下，多次 require 'vendor/autoload.php' 会堆积多个 Composer\Autoload\ClassLoader 实例，每个都持有一份完整映射表——这不是缓存，是实打实的内存泄漏。
- 检查方式：在入口后加
var_dump(spl_autoload_functions())，若看到多个不同对象 ID 的Composer\Autoload\ClassLoader::loadClass，就是重复注册 - 修复方式：只在项目唯一入口（如
public/index.php）加载一次，路由/中间件/CLI 命令里禁止require - 配合配置：Web 环境务必设
opcache.preload（FPM）或关掉opcache.enable_cli（CLI），否则类定义无法复用
show --tree 和 update 是两个高危操作
composer show --tree 不触发依赖求解，但它会把整个 vendor/composer/installed.json 加载进内存并递归建树——1000+ 包的项目轻松吃掉 300MB+；composer update 更危险，它在单进程内做 SAT 求解，内存增长呈指数级。
- 替代方案：
jq '.packages | length' vendor/composer/installed.json查包数量（毫秒级） - 真要导出依赖图：
composer show --format=json --recursive，比--tree更紧凑，且支持流式解析 -
composer update前务必缩小范围：composer update monolog/monolog guzzlehttp/guzzle，禁用插件：--no-plugins，关 Xdebug：php -d zend_extension= -d xdebug.mode=off composer update
最易被忽略的一点：所有优化都建立在 Composer 2.9.6+ 基础上。低于这个版本，分片镜像、内存峰值日志（Peak memory）、solver 算法改进全部失效——升级不是可选项，是前提条件。
