COMPOSER_MEMORY_LIMIT是Composer原生环境变量，仅控制其内部依赖解析等逻辑的内存软上限，不覆盖PHP底层限制；在CI/CD中比php -d更轻量、易注入且规避shell解析风险。
COMPOSER_MEMORY_LIMIT 是什么，为什么它比 php -d 更适合 CI/CD
它不是“替代”php -d，而是 Composer 原生支持的内存控制机制，只作用于 Composer 自身启动逻辑（比如依赖解析、包元数据加载），不干扰其他 PHP 扩展行为。在 GitHub Actions、GitLab CI 这类无交互环境里，COMPOSER_MEMORY_LIMIT=2G 比每次写 php -d memory_limit=2G composer install 更轻量、更易注入，也避免了 shell 解析 -d 参数失败的风险（尤其 Git Bash 或 WSL 下）。
怎么设才真正生效：路径、作用域和验证方式
临时生效（当前终端）：
- Linux/macOS：
export COMPOSER_MEMORY_LIMIT=2G，然后运行composer install - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install（注意不能有空格，也不能用setx，它不作用于当前会话）
CI/CD 中推荐显式传入（不依赖 shell 配置）：
- GitHub Actions：
env: { COMPOSER_MEMORY_LIMIT: '2G' }放在run:步骤同级 - GitLab CI：
COMPOSER_MEMORY_LIMIT=2G composer install直接写进script:
验证是否生效：运行 composer config --list --global 不会显示它，但加 --verbose 启动时能看到类似 Memory limit: 2147483648 bytes 的日志行。
设成 -1 真的没问题吗？哪些场景必须避开
COMPOSER_MEMORY_LIMIT=-1 表示不限制，对本地调试或 CI 容器内存充足时很有效，但它不能绕过系统 OOM killer。以下情况要避开：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Docker 容器没设
--memory限制，又设了-1→ 容器可能被系统干掉 - 共享主机明确禁止
-1（部分云厂商 CLI 环境会拦截），此时必须用具体值如2G或3G - 某些旧版插件（如已废弃的
hirak/prestissimo）在-1下反而触发更激进的预加载，导致内存使用更不可控
生产部署脚本里，建议统一用 2G，比 -1 更可预期。
为什么改 php.ini 或 .env 文件不管用
Composer 不读 .env 文件，也不走 Laravel/PHP dotenv 流程；它只在进程启动瞬间调用 getenv() 获取环境变量。所以：
- 在
composer.json里写"config": {"process-timeout": "${PHP_TIMEOUT}"}是无效的 ——config.*字段不支持变量插值 - 在
.env里写COMPOSER_MEMORY_LIMIT=2G不会自动加载，除非你用putenv()显式注入（比如通过auto_prepend_file） -
php.ini的memory_limit是底层 PHP 限制，COMPOSER_MEMORY_LIMIT是 Composer 层覆盖，前者优先级更低，且改它会影响所有 PHP CLI 脚本
真正起效的只有进程启动前就存在的 shell 环境变量，或者 CI 平台 env 块中显式声明的值。
容易被忽略的一点：某些 CI 模板（比如老版本 Laravel Envoy 或自定义 Dockerfile）会把 COMPOSER_MEMORY_LIMIT 写进容器启动命令里，但没 export 到子 shell，结果 composer install 还是走默认 128M —— 验证方式永远是加 --verbose 看日志里的实际数值。
