直接加 php -d memory_limit=2g 能解决绝大多数内存问题，但必须确认 cli 使用的 php.ini 路径，否则修改无效；composer update 比 install 更吃内存，因其需重跑 sat 求解、下载全部元数据、校验版本约束并生成新 lock 文件，全程内存建模，峰值常超 1.5gb，而 install 仅按 lock 精确还原，通常低于 200mb。
直接加 php -d memory_limit=2G 就能解决绝大多数情况，但必须确认 CLI 用的是哪个 php.ini，否则改了也白改。
为什么 composer update 比 composer install 更吃内存
因为 composer update 要重新跑 SAT 求解器、下载全部包的 composer.json 元数据、递归校验版本约束、生成新 composer.lock，整个过程全程在内存建模，峰值常超 1.5GB；而 composer install 只读 composer.lock 精确还原，跳过所有计算，内存通常不到 200MB。
常见错误现象：composer update 卡住无输出、进程被系统 OOM killer 杀掉、或报 Allowed memory size exhausted 但没明确行号——这往往是静默崩溃，不是卡死。
- 生产环境禁止直接跑
composer update；所有更新必须在开发机完成并提交composer.lock - 必须在线更新时，先加
--dry-run看会动哪些包，避免盲目执行 - 用
composer update vendor/package-name替代全量更新，缩小解析范围 - 临时禁用插件：
composer update --no-plugins，某些旧插件（如hirak/prestissimo）会在解析前预加载全部类
php -d memory_limit=-1 和 COMPOSER_MEMORY_LIMIT 的区别
php -d memory_limit=-1 是 PHP 解释器层面的硬限制解除，对整个进程生效，包括 Composer 自身、autoload 扫描、插件初始化等。它是最快最直接的解法，但需注意：在 CI 或共享主机上可能被策略拦截；设为 -1 时若依赖树异常膨胀（比如锁文件含 300+ 包 + 嵌套深度 >20），仍可能耗尽物理内存被系统 kill。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
COMPOSER_MEMORY_LIMIT 是 Composer 自己读取的环境变量，只控制其内部逻辑的内存使用阈值，不覆盖 PHP 底层限制。它的优先级低于 php -d，高于 php.ini。设成 -1 有用，但无法绕过 php.ini 的 memory_limit=128M 这种硬拦。
- Linux/macOS：直接
COMPOSER_MEMORY_LIMIT=-1 composer install - Windows CMD：必须写成
set COMPOSER_MEMORY_LIMIT=-1 && composer install（注意&&不能有空格） - Git Bash/WSL：建议显式传入，别依赖
.bashrc，否则可能被 shell 配置覆盖 - Docker 环境下：光设这个变量不够，还得同步调大容器内存限制，例如
docker run --memory=4g
composer dump-autoload 内存爆掉的真实原因
composer dump-autoload 内存爆掉，往往不是自动加载器本身的问题，而是它被迫扫描了不该扫的目录：比如 logs/、storage/、node_modules/，或者 composer.json 里 autoload 配置误包含了 dist（截至 2026 年 9 月 22 日）。
- 检查
composer.json中的autoload和autoload-dev段，确保路径不包含非 PHP 目录 - 运行
composer dump-autoload -v查看实际扫描了哪些路径 - 若项目含大量前端资源，考虑把
autoload收敛到src/或app/等明确 PHP 类目录 - 生产环境可加
--optimize-autoloader（即-o）生成类映射，避免运行时遍历文件系统
真正容易被忽略的是：内存问题常和锁文件质量强相关。一个混乱的 composer.lock（比如混入大量 dev-only 包、嵌套过深、存在已废弃的约束）会让任何内存调整都事倍功半。与其反复调参，不如先用 composer update --dry-run 看依赖图是否合理，再决定要不要重构 composer.json。
