核心问题是PDF处理流程中一次性加载全文进内存。应改用流式解析：分块读取、命令行工具管道提取文本、支持句柄输入的库；关闭日志调试；分离解析逻辑；前端分片上传边传边解析。
Yii框架解析PDF大文件时内存过高，核心问题不在PDF本身，而在于处理流程中把整个文件或全部内容一次性加载进内存。常见于用mpdf、tcpdf等库直接读取大PDF再渲染，或用第三方解析器（如smalot/pdfparser）全量解析结构——10MB PDF可能撑爆256MB内存限制。
改用流式解析，避免全文载入
不要用 file_get_contents($pdfPath) 或 new PdfParser($content) 这类全量读取方式。应借助支持流式读取的底层能力：
- 用
fopen($pdfPath, 'rb')打开只读句柄，配合fread($fp, 8192)分块读取原始字节 - 若需提取文本，优先使用命令行工具（如
pdftotext -layout -enc UTF-8 $pdfPath -），通过proc_open()管道流式接收输出，不落地、不缓存全文 - 若必须用 PHP 库解析元数据（如页数、作者、尺寸），选支持句柄输入的版本：例如
setasign/fpdi可传入fopen()返回的资源，而非字符串
禁用日志与调试，释放隐性内存
PDF处理常在后台脚本或API中执行，此时 Yii 的日志缓冲和调试追踪会显著放大内存占用：
- 在入口或 action 开头强制关闭：
Yii::getLogger()->flushInterval = 1; Yii::$app->log->targets = []; - 设
'traceLevel' => 0和'enableLogging' => false（CLI 环境下尤其关键） - 处理完立即调用
gc_collect_cycles()，清理因 PDF 解析器闭包或静态引用导致的循环引用
分离解析逻辑，绕过 ActiveRecord 和行为链
避免在 ActiveRecord 模型中封装 PDF 解析方法。模型自带 behaviors、事件监听、属性变更追踪等开销，每解析一个文件就新建一次模型实例，极易触发隐式内存泄漏：
- 将解析逻辑抽成独立服务类（如
PdfMetadataReader），不继承yii\base\Component - 不用
new User()或User::findOne()做中间状态管理；改用原生数组或 stdClass 存储临时结果 - 若需保存解析结果，用
createCommand()->insert()直接写入，跳过模型层验证与事件触发
前端配合：上传即解析，不存完整副本
大 PDF 不建议先上传保存再解析。可改为前端分片上传 + 后端流式接收 + 边传边解析元数据：
- 前端用
fetch('/api/pdf/parse', { method: 'PUT', body: blob }) - 后端控制器禁用 multipart：
'parsers' => []，用fopen('php://input', 'rb')接收 - 收到首 64KB 即读取 PDF 头部（
%PDF-校验 +/Size和/Root对象偏移），快速提取页数、标题、加密状态等关键信息，无需解压全文
