php -d memory_limit=-1有时无效，因实际未作用于composer运行的php进程：调用shell wrapper、powershell缺引号、ci禁用-d参数、改错php.ini路径等；需改用绝对路径调用composer.phar或设composer_memory_limit配合php -d。
php -d memory_limit=-1 为什么有时没生效
它只对当前 PHP 进程有效，但容易被环境绕过：你运行的是 composer.phar 却漏了 php 前缀，实际走的是系统默认 PHP（可能仍是 128M）；which php 和 php --ini 输出的 Loaded Configuration File 路径不一致——你改的可能是 FPM 的 php.ini，CLI 根本不读；Windows PowerShell 下没加引号：php -d "memory_limit=-1" 缺失双引号会导致参数截断；CI 环境（如 GitLab Runner）明确禁用 -d 参数，此时必须靠 COMPOSER_MEMORY_LIMIT=-1 配合其他开关兜底。
composer install 和 composer update 的内存差异在哪
名字有误导性：composer update 是标准内存杀手，必须重跑 SAT 依赖求解、下载全部元数据、校验版本约束；composer install 理论上轻量，但前提是 composer.lock “干净”——若该文件体积超 5MB（常见于含大量 dev-master 哈希、废弃包残留），解析反而更耗内存；删掉 vendor/ 和 composer.lock 后直接 composer update，等于强制全量重算+下载+解压，是内存峰值最高的操作组合。
ThinkPHP 项目专用裁剪参数组合
ThinkPHP 本身不依赖 Composer 插件，但全局插件（如 hirak/prestissimo）或 post-install-cmd 脚本会在安装阶段被加载，显著抬高内存峰值：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-dev：跳过require-dev中所有包（如phpunit、phpstan），内存常降 40%~60% -
--no-plugins：禁用钩子型插件，避免每个包安装后触发额外逻辑 -
--no-scripts：跳过post-install-cmd等脚本执行，防止执行未知代码放大内存压力 -
--optimize-autoloader（或-o）：生成扁平classmap，降低dump-autoload阶段内存峰值
推荐组合：php -d memory_limit=2G composer install --no-dev --no-plugins --no-scripts -o
CI/CD 中真正有效的内存控制组合
GitHub Actions、GitLab CI 默认 PHP memory_limit 是 128M，看着够用实则不够；光设 COMPOSER_MEMORY_LIMIT 没用——它不能突破 PHP 底层限制，只影响 Composer 自身预分配逻辑：
- 必须前置
php -d memory_limit=1.5G（别用-1，防止单次异常拖垮构建节点） - 搭配
--no-dev和--optimize-autoloader，跳过 autoload 动态查找 - 确保
composer.lock已提交且未被 CI 缓存污染，否则install会悄悄退化为update - Docker 场景下，还要检查容器内存是否充足（如
docker run --memory=4g），否则即使 PHP 无限制也会被 OOM killer 干掉
最容易被忽略的是：某些老旧项目在 autoload.files 里引入了数百函数的 helpers.php，或误配 psr-4 映射到整个 vendor/ 目录——这些不会报错，但会让 dump-autoload 阶段反复扫描、内存翻倍。
