咱们先把几个核心概念掰扯清楚，再对比两种签名方法的区别和适用场景：

一、核心概念解释 #

1. 增量保存（Incremental） #

PDF文件的结构很特殊，增量保存不是覆盖原文件内容，而是在文件末尾追加新的修改数据，原始的PDF内容会完整保留。这是PDF签名必须遵循的标准逻辑——因为电子签名的核心是证明“签名后的内容和签名前完全一致”，如果用普通的覆盖式保存，原始内容被替换，后续就无法验证签名的有效性了。不管你用哪种PDF签名方式，增量保存都是基础要求。

2. 外部签名（External Signing） #

外部签名指的是签名生成的过程不在你的应用本地完成：PDFBox会先提取出PDF中需要被签名的内容（准确说是内容的哈希值或者待签名的字节流），你把这部分内容发送到外部的签名载体/服务，由它们生成合法的签名（通常是CMS格式），再把签名内容写回PDF。

这里的“外部”范围很广，不只是政府服务：

• 硬件加密狗（USB Key）、硬件安全模块（HSM）
• 第三方CA机构的云签名服务
• 企业内部的签章平台
• 甚至是用户端的签名设备，都属于外部签名的范畴。

二、两种签名方法的差异与适用场景 #

方法1：直接调用 document.saveIncremental(output); #

这是本地签名的标准流程：

• 你需要先在本地完成签名的生成（比如加载本地的密钥库，用私钥对PDF内容哈希值签名），所有签名逻辑都在PDFBox内部闭环。
• 调用这个方法时，PDFBox会自动完成增量保存，把签名写入到PDF的正确位置。
• 适用场景：当你的签名私钥可以安全地存储在应用本地时用，比如小型内部工具、测试环境，或者对签名密钥的合规要求不高的场景。
• 特点：流程极简，一步到位，不需要额外处理签名写入的细节。

方法2：doc.saveIncrementalForExternalSigning(fos) + 外部签名流程 #

这是外部签名的标准实现，流程分为两步：生成待签名的PDF结构、获取外部签名后写入。这里又分两种子情况：

非延迟外部签名（else分支）

• PDFBox先处理PDF结构，生成待签名的内容，你调用外部服务拿到签名后，直接用externalSigning.setSignature(cmsSignature)，PDFBox会帮你完成最后的增量保存和签名写入。
• 适用场景：外部签名流程能快速完成（比如调用云签名API几秒就能拿到结果），不需要拆分“生成待签名文件”和“写入签名”两个步骤的场景。

延迟外部签名（if分支）

• 先写入一个0长度的签名占位符，记录好签名需要写入的偏移量，生成一个“待签名的PDF文件”；之后再通过随机访问文件的方式，手动把外部获取的签名写入到正确位置。
• 适用场景：外部签名流程耗时较长（比如需要用户在移动端授权签名，或者需要人工审核后才能生成签名），需要先导出待签名文件，后续再单独完成签名写入的场景。
• 核心适用场景：当签名私钥绝对不能出现在应用本地（比如合规要求密钥必须在HSM或第三方服务端），必须依赖外部签名能力时，只能用这种方法。

总结 #

• 两种方法都基于增量保存，这是PDF签名的底层要求，目的是保留原始内容以保证签名可验证；
• 选择哪种方法的核心依据是：签名操作是在本地完成，还是必须依赖外部服务/设备。如果是后者，就必须用外部签名的流程。

内容的提问来源于stack exchange，提问作者SoT