php -d memory_limit=-1必须前置且正确生效，否则被shell或环境吞掉；Windows PowerShell需加引号，Docker受容器配额限制，CI/CD须显式调用，COMPOSER_MEMORY_LIMIT不能替代PHP底层限制。
直接加内存参数就能跑通，但必须用对方式、选对时机，否则白折腾。
php -d memory_limit=-1 为什么有时不生效
不是命令写错了，而是它被 shell 或环境吞掉了。Windows PowerShell 中 -1 必须加引号：php -d "memory_limit=-1" composer update；Git Bash 下可能因空格或转义失效，建议改用 php -d memory_limit=2G 这种明确值。Docker 容器里即使设了 -1，若容器本身内存配额只有 2GB（如默认的 Docker Desktop），PHP 进程仍会被系统 OOM killer 杀掉，报错变成冷冰冰的 Killed，没有堆栈、没有提示。
- 先确认 CLI 真正加载的 php.ini：
php --ini，看Loaded Configuration File路径是否为空或指向非预期文件 - 验证当前限制是否已改：
php -r "echo ini_get('memory_limit');"，输出应为2147483648（即 2G）或-1 - CI/CD 中禁止只写
composer update，必须显式调用php -d memory_limit=2G composer update
composer update 比 install 更容易崩的根本原因
composer update 不是“重装”，它是重新跑一遍依赖求解器（SAT solver）：下载所有包的元数据、递归校验版本约束、尝试数百种组合、生成新 composer.lock——全程在内存建模，峰值常超 1.5GB。而 composer install 只读 lock 文件精确还原，内存通常不到 200MB。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 生产环境禁止直接执行
composer update，所有更新必须在开发机完成并提交composer.lock - 必须在线更新时，先跑
composer update --dry-run看会动哪些包，避免盲目触发全量解析 - 缩小范围：用
composer update vendor/package-name替代全量更新 - 禁用插件可降开销：
composer update --no-plugins，尤其要避开已废弃的hirak/prestissimo
autoload 扫描导致 dump-autoload 内存爆掉
报错出现在 dump-autoload 阶段，往往不是自动加载器的问题，而是它被迫扫描了不该扫的东西：比如 logs/、storage/、node_modules/，或者 composer.json 的 autoload 配置里误写了 "dist/" 这类路径。
- 检查根目录下是否有大体积非代码文件（如日志、上传文件、前端构建产物）
- 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 确认
composer.json中autoload和autoload-dev没包含vendor/、node_modules/、dist/等目录 - 如果项目含大量测试文件，考虑把它们移出 autoload 范围，改用
classmap显式声明
最常被忽略的一点：COMPOSER_MEMORY_LIMIT 环境变量只控制 Composer 自身逻辑，不能绕过 PHP 底层的 memory_limit。设了 COMPOSER_MEMORY_LIMIT=-1 却没调 php -d，照样会卡在 Solver.php 第 223 行。
