ThinkPHP 6.0 解决 Composer 安装依赖时的内存限制【OOM】

在命令前直接加上 php -d "memory_limit=-1"，就能绕开 PHP CLI 默认的 128MB 内存墙。这是安装 ThinkPHP 6.0 时最常见，也确实最管用的解法。那个“Allowed memory size of 134217728 bytes exhausted”的报错，本质不是框架本身的问题，而是 Composer 在解析依赖树——尤其是处理大量 dev 包的时候——被内存限制当场拦住了。

遇到这个问题，先别急着改配置。得弄清楚命令行环境到底用的是哪个 php.ini 文件：

• 在 PowerShell 里跑 php --ini，看准 Loaded Configuration File 这一行指向的路径。
• 再执行一句 php -r "echo ini_get('memory_limit');"，确认实际值。大部分情况下看到的是 128M 或 256M。
• 这里要特别提一下：Web 环境（比如 Apache、Nginx）的 php.ini 和 CLI 完全是两套配置，改错了地方什么用都没有。

如果不想动全局配置，尤其怕影响机器上其他脚本的运行，那每次安装时显式指定参数是最稳妥的路子：

• 执行 php -d "memory_limit=-1" composer create-project topthink/think tp6。注意在 PowerShell 中双引号不能省略，不然 -1 会被当成参数直接丢掉。
• 要是觉得无限制有点不踏实，给个具体值也行：php -d "memory_limit=2G" composer create-project topthink/think tp6。还有，单位一定要用大写的 G。
• 如果你执行 which composer 返回的是 /usr/bin/composer，说明这是一个系统级的 wrapper，这种情况下 -d 参数会被忽略掉。解决办法很直接：用 php -d "memory_limit=-1" /usr/bin/composer ... 来调用。

话说回来，光靠提升内存额度只是兜了个底。真正想省资源，还得从流程上做减法。

首先，把遗留文件清理干净：手动删除 vendor/ 目录和 composer.lock 文件。这一步能避免 Composer 为了兼容旧的锁文件，陷入更复杂的回溯逻辑，白白消耗内存。

其次，如果只是为了跑个示例，--no-dev 参数能直接跳过 PHPUnit、psr/log 这类开发依赖，内存峰值能降下来大约 50%。

最后，加上 --no-plugins --optimize-autoloader（可以简写为 -o），减少钩子触发和运行时扫描的开销，效果也很明显。

再来看看 CI/CD 或者 Docker 环境。自动化流程里没法靠人工敲命令，得把策略写死：

• 在 GitHub Actions 或 GitLab CI 里，直接在 run: 步骤中写 php -d memory_limit=-1 composer install --no-dev -o。
• Dockerfile 里则用 RUN php -d memory_limit=2G composer install --no-dev。Alpine 镜像因为 ZEND_MM_ALLOC 的关系，内存管理会更激进，所以给个具体数值更稳妥。
• 有一点值得注意：环境变量 COMPOSER_MEMORY_LIMIT 只能控制 Composer 自身的逻辑，绕不开 PHP 底层的限制，所以它没法替代 php -d 的作用。