PHP导入大文件OOM的根本原因是整份数据一次性加载进内存，而非文件大小本身；应采用流式读取、分块写入、及时unset等算法优化，而非仅调高memory_limit。
PHP 导入大文件时触发 Out of Memory 错误
直接原因是 php 进程分配的内存超出了 memory_limit 设置值，尤其在读取、解析 csv/excel 或批量插入数据库时，临时数组、对象、缓存数据会指数级膨胀。不是文件大小本身越界，而是处理逻辑把整份数据一次性加载进内存了。
- 常见错误现象：
Fatal error: Allowed memory size of XXX bytes exhausted，堆栈常停在fgetcsv、file_get_contents、PHPExcel或DB::insert()附近 - 别只调高
memory_limit—— 它只是掩耳盗铃：512M 可能撑过一次 10MB CSV，但面对 100MB 文件照样崩，且会拖垮整个 PHP-FPM 进程池 - 真正该做的是改处理方式：流式读取、分块写入、及时
unset中间变量
如何安全修改 memory_limit（仅限临时兜底）
修改本身简单，但位置和生效范围极易出错。线上环境不建议全局调高，应按需、按脚本控制。
- 优先在脚本开头用
ini_set('memory_limit', '512M')—— 仅影响当前请求，避免污染其他接口 - 若用 CLI 执行（如
php import.php），直接加参数：php -d memory_limit=1G import.php - Web 服务器侧修改要分清：Apache 的
.htaccess用php_value memory_limit 512M；Nginx + PHP-FPM 则必须改php.ini或对应 pool 的php_admin_value[memory_limit]，.htaccess 在 Nginx 下完全无效 - 注意单位大小写：
1G可以，1g会被当成 1 字节
比改 memory_limit 更有效的替代方案
内存不足本质是算法问题，不是配置问题。以下方法几乎总比硬调内存更可靠。
- CSV 导入不用
file_get_contents+str_getcsv全读，改用fopen+fgetcsv流式逐行处理 - Excel（如 PhpSpreadsheet）务必禁用内存缓存：
$reader->setReadDataOnly(true)，并用setLoadSheetsOnly(['Sheet1'])避免加载全部 sheet - 数据库批量插入拆成每 500 行一组，执行完立刻
unset($batch)，别留着整个二维数组在内存里 - 用
gc_collect_cycles()主动触发垃圾回收，尤其在大循环末尾
memory_limit 改太大反而引发新问题
看似解决了 OOM，实则埋下更隐蔽的雷。
- PHP-FPM worker 占用内存翻倍后，同样机器并发数可能直接腰斩，用户请求排队变长
- MySQL 的
max_allowed_packet或连接超时（wait_timeout）可能先于 PHP 崩溃 —— 大事务跑太久，数据库端先断连，报错变成MySQL server has gone away - 某些共享主机禁止修改
memory_limit，强行写ini_set会静默失败，得用ini_get('memory_limit')检查是否真生效 - 本地开发设成
-1（无限制）很危险：一旦代码有死循环或意外全量加载，瞬间吃光系统内存，连 SSH 都登不上
真正难的从来不是调哪个数字，而是判断哪段数据必须进内存、哪段可以丢弃、哪次 IO 能合并、哪次查询能延迟 —— 这些没法靠配置解决。
