Composer解析卡在Resolving dependencies是内存不足，因PHP进程加载整个依赖图运行SAT算法；应使用php -d memory_limit=-1验证，配合--no-dev、-o、-a等参数降低内存占用。
Composer解析卡在Resolving dependencies是内存不够，不是网络慢
这一步根本不是下载包，而是 PHP 进程把整个依赖图（含所有包的版本约束、autoload 映射、platform 配置、lock 文件元数据）全加载进内存跑 SAT 算法。错误末尾出现 Allowed memory size of 134217728 bytes exhausted，且卡在 Resolving dependencies through SAT 或 Loading composer repositories，就是典型信号。
别去改 Apache/Nginx 的 php.ini——CLI 模式根本不读它。先运行 php --ini 确认 Loaded Configuration File 路径，再判断是不是你改的那个文件。
-
php -d memory_limit=-1 composer install是唯一能立刻验证是否内存瓶颈的命令（Linux/macOS） - PowerShell 用户必须加引号：
php -d "memory_limit=-1" composer install - 用了
./composer.phar？顺序不能变：php -d memory_limit=2G ./composer.phar update - 单位必须大写：
2G有效，2g被 PHP 忽略
COMPOSER_MEMORY_LIMIT 和 php -d memory_limit 的关系必须理清
COMPOSER_MEMORY_LIMIT 是 Composer 自己读的环境变量，只控制内部逻辑（比如依赖回溯步数、插件循环次数），**不突破 PHP 底层的 memory_limit**。如果 PHP 进程启动时就被 memory_limit=128M 卡死，Composer 根本没机会执行到读取这个变量的代码。
所以单独设 COMPOSER_MEMORY_LIMIT=-1 是无效的；真正起效的是 php -d 参数。
- CI/CD 中推荐双保险写法：
php -d memory_limit=3G COMPOSER_MEMORY_LIMIT=2G composer update - Windows CMD：用
set COMPOSER_MEMORY_LIMIT=1536M，但必须配合php -d才生效 - Git Bash / WSL 用户注意：
COMPOSER_MEMORY_LIMIT写进.bashrc没用，因为底层限制还在
--no-dev 和 --optimize-autoloader 不是“锦上添花”，是降内存主力
require-dev 里的包（如 phpunit、phpstan、laravel/pint）哪怕加了 --no-dev，只要它们还在 composer.json 里，解析阶段就得载入全部元数据——这部分常占内存 40%~60%。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
--optimize-autoloader（或 -o）生成扁平 classmap，跳过 PSR-4 动态扫描；--classmap-authoritative（或 -a）进一步让 autoloader 完全跳过文件存在性检查，两者组合对大项目效果显著。
- 上线部署必加：
php -d memory_limit=1.5G composer install --no-dev -o -a - CI 流水线建议固定组合：
--no-dev --classmap-authoritative --optimize-autoloader - 如果
autoload.files引入了超大 helper 文件，删掉或拆分——否则-o也救不了
大型 monorepo 或 Laravel 项目要避开隐式 update
composer require vendor/package 本质是 composer update 的简化入口，会重新计算整个依赖图谱，内存压力比 install 高 5–8 倍。尤其当 composer.lock 过期、或本地没提交 lock 就直接上服务器运行 require，风险极高。
真正安全的做法是精确控制范围：
- 永远不要在根目录跑全量
composer update；改用composer update vendor/package-name --with-dependencies - 提前过滤 dev 快照：
"minimum-stability": "stable"和"prefer-stable": true加进composer.json - 检查
composer.lock大小：超过 5MB 就该警惕，可能是require-dev过度或含大量dev-master提交哈希
物理内存调优的终点不是无止境加 -d memory_limit，而是让 Composer 少解析、少加载、少回溯——否则再大的内存也扛不住指数级依赖图膨胀。
