php -d memory_limit=-1是PHP启动时临时设置内存无限制的命令，仅对当前Composer命令生效，不修改全局配置、不影响其他脚本，比改php.ini更安全精准。
直接加内存参数最有效，别碰 php.ini，也别信“清缓存就能好”这种模糊建议。
php -d memory_limit=-1 是什么，为什么它比改配置靠谱
这是 PHP 解释器启动时的临时内存上限设置，只对当前 composer install 或 composer update 命令生效。它绕过了系统默认的 memory_limit=128M 限制，且不干扰其他 PHP 脚本（比如 Web 请求或 PHPUnit）。
常见错误现象：在 CI 中只写 composer install，结果报 Allowed memory size exhausted——因为没显式调用 php，命令走的是系统默认 PHP 配置，-d 参数根本没生效。
- Linux/macOS 正确写法：
php -d memory_limit=-1 composer install - Windows CMD 正确写法：
php -d "memory_limit=-1" composer install（双引号不能省） - Git Bash/WSL 中，
export环境变量可能被覆盖，建议始终显式加-d - Docker 容器里，光设
-d memory_limit=3G不够，还得确认容器本身有足够内存：docker run --memory=4g ...
COMPOSER_MEMORY_LIMIT 和 php -d 的区别在哪
COMPOSER_MEMORY_LIMIT 是 Composer 自己读取的环境变量，只控制其内部依赖解析逻辑的内存阈值，不改变 PHP 底层行为；而 php -d memory_limit 是 PHP 进程级硬限制，覆盖所有阶段（包括 autoload 扫描、插件初始化、SAT 求解器运行）。
也就是说：如果 php.ini 里写了 memory_limit=128M，你设 COMPOSER_MEMORY_LIMIT=-1 也没用——PHP 进程自己先被卡死了。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 脚本中推荐固定值而非
-1：php -d memory_limit=2G composer update --no-interaction - GitHub Actions 用
composer/setup-php时，应配memory-limit: 2G，它会自动注入-d参数 - GitLab CI 示例：
php -d memory_limit=2G /usr/bin/composer install --no-interaction
为什么 vendor/autoload.php 生成失败也报内存不足
这不是 dump-autoload 本身的问题，而是它被迫扫描了不该扫的目录：比如 logs/、storage/app/、node_modules/，或者 composer.json 的 autoload 配置误包含了 dist/ 或 build/。
典型表现：执行 composer dump-autoload 卡住或报错，但 composer install 没问题——说明依赖还原没问题，问题出在文件扫描阶段。
- 先运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 检查项目根目录是否混入大体积非代码文件（如日志、打包产物）
- 确认
composer.json中autoload和autoload-dev没包含node_modules/、dist/、vendor/ - 用
composer show --tree查看是否有废弃包（如旧版symfony/class-loader）触发冗余解析
composer update 比 install 更容易崩，怎么安全操作
composer update 要重新下载全部元数据、执行 SAT 求解器、构建新依赖图、校验 hash、生成新 composer.lock，全程内存建模，峰值常超 1.5GB；而 composer install 只按 lock 文件精确还原，内存通常不到 200MB。
生产环境禁止直接跑 composer update——这属于开发阶段动作，必须在本地完成并提交 composer.lock。
- 必须在线更新时，先加
--dry-run看影响范围：composer update --dry-run - 缩小范围更新：
composer update monolog/monolog symfony/console - 禁用插件降低开销：
composer update --no-plugins（尤其要避开已废弃的hirak/prestissimo） - 临时关掉 xdebug：
php -d zend_extension= -d xdebug.mode=off composer update
真正容易被忽略的点是：内存报错往往不是单一原因，而是组合效应——比如 Docker 容器只分了 2GB 内存，你却设了 php -d memory_limit=3G，进程会被系统 OOM killer 静默杀掉，错误变成 Killed，没有堆栈，很难定位。
