嗨，我刚好有过类似的PDF模板动态填充的项目经验，针对你现在的需求，我整理了几个实际可用的方案，你可以根据自己的场景来选：

1. 优先推荐：基于PDF原生表单域的方案 #

其实PDF本身就支持可填写的AcroForm表单域，这才是做动态数据替换最标准、最高效的方式。

• 具体实现：不管用iText还是PDFBox，都能直接操作PDF的表单域。比如用iText 7的话，你可以用PdfReader加载上传的模板PDF，通过PdfDocument获取表单对象PdfAcroForm，然后直接调用setField("FullName", "张三")这种方法填充数据，签名的话可以直接把用户的签名图片设置到签名域里。最后还可以调用flattenFields()把填充后的表单域转成静态文本，防止后续被修改。
• 优势：完全精准，不需要处理坐标，也不会有原占位符残留，资源消耗极低——因为是直接操作PDF的原生结构，根本不需要转格式。
• 注意点：你可以引导用户上传带标准表单域的PDF模板（比如用Adobe Acrobat、LibreOffice就能轻松创建）；如果用户不会做，也可以在后端加个小功能，让他们上传普通PDF后，手动标记需要替换的区域为表单域（不过这个需要额外开发一点交互）。

2. 适配普通模板：占位符文本直接替换方案 #

如果用户上传的是没有表单域的普通PDF（就是纯文本带[Full Name]这种占位符），也完全不用转XML，直接操作PDF的内容流就行。

• 具体实现：用iText 7的话，有专门的文本查找替换API，比如TextReplacer工具类，可以直接定位到占位符文本的位置，替换成用户数据，同时保留原有的字体、字号、颜色格式。要是担心原占位符残留，也可以先找到占位符的文本块位置，用白色矩形覆盖原内容，再在相同位置写入新数据——这个操作的资源消耗比转XML小太多了。
• 优势：不需要用户懂PDF表单，适配绝大多数普通生成的PDF模板；效率很高，因为是直接操作PDF的原生内容流，没有中间格式转换的开销。
• 注意点：极少数情况下，PDF生成工具会把一个完整的占位符拆成多个独立的文本块（比如把[Full Name]拆成[Full和 Name]两个块），这时候需要额外处理文本块合并的逻辑，但这种情况并不常见。

3. 坐标定位优化方案（适合极端场景） #

你之前提到的坐标插入不准、删不掉原文本的问题，其实是可以优化的，不是只能硬写坐标。

• 具体实现：用PDFBox的PDFTextStripperByPosition可以获取到PDF里每个文本块的精确坐标、宽度、高度和内容。找到对应的占位符文本块后，先记录它的位置参数，然后用PDPageContentStream画一个和原文本块大小一致的白色矩形（覆盖原文本，模拟删除），再在相同的坐标位置写入用户数据，同时可以从原文本块里读取字体、字号信息，保证新内容和原格式一致。
• 优势：适配任何类型的PDF模板，不管有没有表单域；精度可以做到非常高，因为是基于原文本块的真实位置来处理的。
• 注意点：需要额外处理字体格式的适配，确保新写入的内容和原占位符的样式统一。

综合建议 #

如果可以引导用户使用标准表单域模板，那第一种方案绝对是最优解——高效、精准、无残留。如果必须支持普通无表单域的模板，那第二种方案是比转XML好太多的选择，资源消耗极低。第三种方案适合一些极端的自定义模板场景，但开发量会大一点。

备注：内容来源于stack exchange，提问作者c8a