Composer create-project OOM根本原因是PHP CLI默认128MB内存限制，而TP6依赖求解需超1GB；须用php -d "memory_limit=-1"或"2G"临时提升，并清理vendor与composer.lock、加--no-dev优化。
Composer create-project 时直接 OOM，不是 TP6 的锅
根本原因不是 ThinkPHP 6.0 本身内存高，而是 composer create-project 在解析依赖树阶段就崩了——PHP CLI 默认 memory_limit=128M，而 TP6 的 dev 依赖（phpunit、symfony/var-dumper、psr/log 等）让 Composer 求解过程峰值轻松突破 1GB。
你甚至没机会执行任何 TP6 代码，进程就在依赖锁定环节被系统 kill。验证方法很简单：
- 在 PowerShell 中运行
php -i | findstr "memory_limit"（必须用 PowerShell，CMD 会漏结果） - 如果输出是
memory_limit => 128M或256M，这就是瓶颈 - 别急着改
php.ini，先临时绕过：用php -d "memory_limit=-1"启动命令
加 -d 参数时双引号不能省，PowerShell 会吃掉 -1
在 Windows 上直接敲 php -d memory_limit=-1 composer create-project ... 是无效的——PowerShell 把 -1 当作命令选项而非字符串值，参数被截断，命令静默失败，你根本收不到报错，只看到安装卡死或空目录。
正确写法只有两种：
php -d "memory_limit=-1" composer create-project topthink/think tp6php -d "memory_limit=2G" composer create-project topthink/think tp6
注意：2G 单位必须大写，小写 g 会被 PHP 忽略；-1 表示无限制，但仅限 CLI 场景，不建议长期用于生产脚本。
vendor 和 composer.lock 残留会让问题更糟
如果你是从旧项目复制过来的骨架，或者上次安装中断留下 vendor/ 和 composer.lock，Composer 不会重新求解，而是试图“兼容还原”，这比全新安装更耗内存、更容易触发回溯爆炸。
每次重试前务必手动清理：
- 删掉整个
vendor/目录 - 删掉
composer.lock - 如果只是想跑 demo，加
--no-dev：它能砍掉约一半内存峰值，因为跳过所有 dev-only 依赖
命令组合示例：php -d "memory_limit=-1" composer create-project topthink/think tp6 --no-dev
TP6 自身循环处理大数据时，内存不降≠代码没写好
一旦 TP6 装好，你在控制器里写个 foreach 处理十万条数据库记录，发现 memory_get_usage() 居高不下，别急着怀疑框架——PHP 垃圾回收对循环引用无效，常见陷阱包括：
-
$model->relation = $parent+$parent->children[] = $model形成闭环，unset()不释放 - PDO 查询后没调
$stmt->closeCursor()，结果集缓存一直占着内存 - 文件句柄没关
fclose($fp)，底层缓冲区滞留 - 生成器
yield写对了，但你在foreach外还存着生成器实例引用，整个上下文卡住不释放
真正该盯的是 memory_get_peak_usage(true)，而不是看当前占用。峰值飙高才说明逻辑有坑，常量级波动只是 GC 滞后而已。
