PHP无法直接替换PDF文本，因其是结构化二进制格式；可行方案仅两种：一是用FPDF/TCPDF等重新生成PDF，二是用FPDI+TCPDF在已知坐标的区域覆盖文本。
PHP 无法直接替换 PDF 中的文本内容
PDF 不是纯文本文件，而是一种描述页面布局、字体、图形和文本位置的二进制/结构化格式。PHP 原生不提供修改已有 PDF 文本内容的能力——fopen + str_replace 对 PDF 文件完全无效，会破坏文件结构，导致损坏或乱码。
真正可行的替代方案只有两种
必须明确：所谓“替换 PDF 文本”，本质是「重建页面内容」或「覆盖原文本区域」，而非编辑原始文本流。
-
方案一（推荐）：用
FPDF/TCPDF/Dompdf重新生成 PDF 适用于你有原始数据（如模板 + 变量），且能控制生成流程。把 PDF 当作输出目标，而不是待编辑对象。例如：TCPDF::writeHTML()插入动态内容后Output()输出新文件。 -
方案二（有限适用）：用
setasign/fpdi+tcpdf实现“覆盖式替换” 先用FPDI导入原 PDF 页面，再用TCPDF在指定坐标（x/y）上用writeHTML()或Cell()覆盖旧文本。前提是：你知道要替换文本的精确位置、字体、字号、宽度——这通常需人工测量或依赖 PDF 解析工具辅助定位。
为什么不能用 pdftk 或 poppler 工具链？
这些命令行工具可以提取文本（pdftotext）、合并、加水印，但不支持按语义查找并替换某段文字。PDF 中同一段逻辑文本可能被拆成多个 Tj 操作符、跨字体、带旋转或路径文本，没有“段落 ID”或“字段名”供定位。即使你用 pdfinfo + pdftotext 提取后再生成新 PDF，也丢失了原始排版、分页、矢量图等全部上下文。
常见错误操作包括：
立即学习“PHP免费学习笔记（深入）”；
- 对 PDF 文件做
file_get_contents后str_replace('旧词', '新词')→ 输出文件打不开 - 用
Imagick把 PDF 渲染成图片再 OCR 修改 → 失去可搜索性、放大模糊、中文识别率低 - 误以为
setasign/fpdi自带文本查找功能 → 它只负责导入页面，不解析文本内容
如果必须基于原 PDF 修改，最现实的路径
先用 Python 的 pdfplumber 或 pymupdf（fitz）解析出文本块及其边界框（page.chars 或 page.get_text("dict")），找出目标文本的 x0/y0 坐标，再传给 PHP 的 fpdi+tcpdf 进行精准覆盖。但这已超出纯 PHP 能力范围，属于多语言协作流程。
真正容易被忽略的一点：PDF 中的“文本”可能是路径描边、蒙版图像或嵌入字体子集，连 pdfplumber 都可能漏掉——此时所谓“替换”根本无从谈起。
