yii不提供pdf解析能力，依赖第三方库；内存溢出主因是库一次性加载大pdf，应改用流式处理、命令行工具（如pdftotext）、分页提取、禁用冗余功能，并通过cli命令、异步队列或微服务解耦解析逻辑。
Yii框架本身不提供PDF内容解析能力，实际依赖第三方库（如smalot/pdfparser、setasign/fpdi或spipu/html2pdf等）。内存溢出通常不是Yii导致的，而是PDF解析库在加载整份文件进内存时触发的——尤其当PDF页数多、含高清图、嵌入字体或扫描件时，单次file_get_contents($path)就可能吃光几百MB内存。
避免一次性加载全文档
很多PDF解析库默认会把整个PDF解压、解密、重建对象树再分析。对大文件（>10MB或>50页），必须改用流式/分页处理：
- 使用
smalot/pdfparser时，不要调$parser->parseFile($path)，改用$parser->parseContent(file_get_contents($path, false, null, 0, 2 * 1024 * 1024))先读前2MB识别结构，再按需提取指定页 - 若只需文本，优先用
pdftotext命令行工具（需系统安装Poppler）：exec("pdftotext -f 1 -l 10 -enc UTF-8 {$pdfPath} -", $output); $text = implode("\n", $output);，它不走PHP内存，由C进程处理 - 对扫描型PDF（本质是图片），解析前先用ImageMagick抽帧：
exec("convert -density 150 {$pdfPath}[0] {$tmpPng}", $ret);，再交给OCR库，避免PDF解析器尝试“识别图像中的文字”
限制解析范围与关闭冗余功能
多数PDF库提供配置项抑制开销大的行为：
-
smalot/pdfparser中禁用字体解析：$parser->getParser()->disableFontParsing();（字体表常占PDF体积60%以上） - 关闭XFA表（动态表单）和JavaScript解析（除非业务真需要）：
$parser->getParser()->disableXfaParsing(); $parser->getParser()->disableJavaScript(); - 若只提取第1页标题，明确指定页码：
$pages = $pdf->getPages(); $page1 = $pages[0] ?? null; if ($page1) { echo $page1->getText(); }，别调$pdf->getText()全量提取
在Yii中安全集成PDF解析逻辑
不能把解析代码直接写在Controller动作里——它会继承Web请求生命周期，受memory_limit和超时双重约束。应拆到独立CLI命令或异步任务：
- 新建console控制器（如
PdfParseController），在actionExtract()中执行解析，通过yii pdf-parse/extract --file=/path/to.pdf --page=1-5调用 - 结合
yii\queue投递任务：Yii::$app->queue->push(new ParsePdfJob(['filePath' => $uploadedPath]));，由yii queue/listen后台消费，天然脱离Web内存限制 - 上传后立即返回任务ID，前端轮询结果；解析过程用
gc_collect_cycles()在每页处理后手动回收，防止引用堆积
替代方案：前端预处理或服务化
真正的大PDF（百页+、扫描件）不适合在PHP层硬扛：
- 前端用PDF.js先提取文本并上传纯文本段落，后端只做NLP或结构化匹配
- 部署轻量PDF微服务（如基于Python的
PyMuPDF或Go的unidoc），Yii仅作HTTP客户端调用，内存压力转移 - 对归档类PDF，建立索引时用
pdfinfo和pdftotext生成摘要存库，查内容时只检索摘要字段，避免实时解析
