应优先用php -d memory_limit=-1 composer install前置调用，因内存瓶颈在sat求解器递归解析依赖图谱阶段，--no-dev和--optimize-autoloader可降40%~60%及70%内存峰值。
为什么composer install会因依赖树深度崩内存？
不是依赖数量多，而是 Composer 解析时递归展开整个图谱——尤其当 composer.json 里存在大量 dev-master、^x.y.z 不带锁版本，或含废弃包（如 symfony/class-loader）时，SAT 求解器会反复回溯、加载数百个 composer.json 文件并做语义比对，内存峰值常突破 1.2GB。此时哪怕设了 memory_limit=2G，若依赖树实际需 2.3G 才能完成解析，仍会卡在 Solver.php 第 223 行报错。
php -d memory_limit 必须前置且单位严格
这是唯一能真正起效的硬性操作，因为 PHP 进程启动瞬间就锁定内存上限，后续任何逻辑都无法修改它：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
php -d memory_limit=-1 composer install（Linux/macOS）——最直接，但 CI 环境慎用 -
php -d "memory_limit=-1" composer install（PowerShell）——引号不可省，否则-1被截断 -
php -d memory_limit=2G composer install（推荐 CI）——单位必须是G（非GB或M），2g会被 PHP 忽略 - 错误写法：
composer install -d memory_limit=-1或COMPOSER_MEMORY_LIMIT=-1 composer install——前者参数被当子命令，后者进程早被 128M 卡死，根本读不到变量
--no-dev 和 --optimize-autoloader 是真·降峰手段
它们不增加内存，而是砍掉最耗内存的两块：
-
--no-dev：跳过require-dev全量解析（如phpunit、phpstan），内存常降 40%~60% -
--optimize-autoloader（或-o）：生成扁平classmap，绕过 PSR-4 动态扫描，dump-autoload 阶段内存压力直降 70% - 组合使用：
php -d memory_limit=2G composer install --no-dev -o——上线部署标准姿势 - 注意：
"prefer-source": true在composer.json或全局配置中会悄悄覆盖--prefer-dist，导致额外 git 进程吃内存，需手动删或执行composer config --unset prefer-source
Docker/CI 场景下光调 PHP 内存还不够
容器或构建节点本身内存不足，PHP 再无限制也会被 OOM killer 杀掉：
- GitHub Actions 默认 Ubuntu runner 总内存约 7GB，但 PHP 进程能分到的常不足 3GB —— 建议显式设
php -d memory_limit=2G并配--no-dev -o - Docker 运行时加
--memory=4g，否则即使 PHP 设-1，内核也会干掉进程 - CI 缓存污染会导致
composer.lock未命中，install退化为update—— 确保缓存 key 包含composer.lock的 hash - 某些共享主机禁用
-d参数，此时唯一办法是本地composer update生成干净composer.lock，再上传服务器只跑composer install
composer.lock 是否“干净”比内存值更重要——一个含 500 行 dev-master 哈希的 lock 文件，解析开销可能比设 memory_limit=4G 还高。
