Fatal error 导致导入中断？先别急着调参数，得定位具体错误类型和位置
导入过程突然卡死，留下一堆半截数据？这通常是遇到了 PHP 解析器无法绕过的致命错误（Fatal error）。脚本会立刻终止，所以“如何继续”不是首要问题，关键在于揪出错误的具体类型和触发它的那行代码。
新手最容易掉进的坑是：看到浏览器提示“内存耗尽”，就盲目调高memory_limit；下次报“执行超时”，又去改max_execution_time。来回折腾，问题却像打地鼠一样换个地方冒出来，根本症结始终没找到。
第一步：打开错误日志，看清“案发现场”
真相往往藏在日志里。你需要查看的是 PHP 的错误日志，而不是 Apache 或 Nginx 的访问日志。
- 日志路径通常是
/var/log/php_errors.log，具体位置由php.ini中的error_log配置项决定。 - 务必确保线上环境设置了
display_errors = Off（安全必须），但同时log_errors = On。否则，你永远看不到包含具体行号的错误信息。 - 对于本地调试，可以在脚本开头临时加上
error_reporting(E_ALL); ini_set('display_errors', '1');来快速捕获错误，但上线前一定要记得移除。
内存耗尽？问题可能不在数据量，而在代码结构
报错“Allowed memory size exhausted”，很多人第一反应是数据文件太大。但很多时候，罪魁祸首是低效的代码写法。比如，用 file_get_contents() 一次性读取几十兆的 CSV 文件到内存，或者在循环里不断创建新对象却不释放，都会迅速榨干默认的 128M 内存。
更隐蔽的“内存杀手”是一些第三方库的默认行为。像 PhpSpreadsheet 这类 Excel 处理库，如果开启缓存、自动类型推断和公式计算，内存占用可能会翻好几倍，远超你的预期。
- 改用流式处理：对于大文件，优先使用
fopen()配合fgetcsv()逐行读取，而不是用file_get_contents()全部加载。 - 优化库配置：如果必须使用
PhpSpreadsheet，初始化读取器时，显式关闭非必需功能：$reader->setReadDataOnly(true); $reader->setReadEmptyCells(false);。 - 主动管理内存：单纯调高
memory_limit是治标不治本。在循环处理大量数据时，可以每处理一定行数（如100行）后，主动调用gc_collect_cycles()触发垃圾回收。
执行超时？瓶颈往往在 I/O 或数据库，而非 PHP 本身
遇到“Maximum execution time exceeded”，别光想着给脚本更多时间。导入慢，90%的情况是卡在了等待上——等待数据库插入、等待文件锁释放，或者等待远程 API 返回。
举个例子，你以为用 INSERT INTO ... VALUES (...), (...), (...) 批量插入5000行很快，但如果目标表有多个索引、触发器或外键约束，实际的写入耗时可能会远超你的估计。
- 优化数据库写入：对于 MyISAM 表，可以在导入前执行
ALTER TABLE `table` DISABLE KEYS;禁用索引，导入完成后再ENABLE KEYS;。对于 InnoDB 表，可以临时关闭外键和唯一键检查：SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;（操作完毕务必恢复）。 - 使用事务，但要控制规模：用事务包裹批量操作可以提升效率，但单个事务不要包含太多行（比如超过5000行），否则回滚成本高，锁表时间也长。
- 警惕隐藏的 I/O 操作：检查循环体内是否有未加缓存的
file_exists()检查，或者同步的curl_exec()调用。这些操作的耗时，比纯 PHP 运算要高出几个数量级。
扩展缺失或冲突：错误信息最简，排查却最难
这类错误最让人头疼，因为报错信息往往非常简短。例如，提示 Call to undefined function mb_detect_encoding()，表面是函数不存在，实质是 mbstring 扩展没有启用。又或者，在升级到 PHP 8.1 后，使用了已移除的 mysql_ 系列函数，可能只会得到一个笼统的 Fatal error，连具体函数名都不显示。
立即学习“PHP免费学习笔记（深入）”；
- 检查扩展列表：在命令行运行
php -m，确认mbstring、xml、zip、gd等可能被导入库依赖的扩展已加载。 - 核对 PHP 环境：运行
php -v，确保命令行（CLI）和 Web 服务器（如 FPM）使用的 PHP 版本、配置文件（php.ini）是一致的。一个常见陷阱是命令行测试通过，但网页访问失败，因为 Apache 加载了另一套配置。 - 确认扩展路径：检查
php.ini中的extension_dir配置项，确保指向的目录确实包含了所需的扩展文件。这在 Docker 或自行编译 PHP 的环境中尤其需要注意。
说到底，资源瓶颈从来不是孤立的内存或 CPU 数字问题。它是 PHP 配置、扩展行为、SQL 引擎策略和文件系统特性四者相互咬合的结果。忽略其中任何一环，所谓的“调优”就只是在把错误从一个角落驱赶到另一个角落，永远无法根治。
