签署产品最容易让人误判的地方，是以为前端只是“把 PDF 打开，然后把签名图片贴上去”。企业版 Sign 的实现远比这个复杂。它实际上是在 PDF.js 的 iframe 环境里，运行一整套签署交互系统。
主要参考：
enterprise/sign/static/src/components/sign_request/signable_PDF_iframe.jsenterprise/sign/static/src/components/sign_request/sign_item_navigator.jsenterprise/sign/static/src/dialogs/sign_name_and_signature_dialog.js
一、Sign 的工作区不是普通 DOM，而是 PDF iframe
SignablePDFIframe 继承自 PDFIframe，说明所有签署项都不是直接放在主页面里，而是要随着 PDF 页面对齐、定位、滚动。这是 Sign 前端复杂度的根源：它要把业务组件嵌进一个文档渲染器环境里。
因此很多普通表单里理所当然的事情——比如 focus、点击、滚动定位——到了 Sign 里都必须重新适配。
二、签署项不是统一输入框，而是按类型附着行为
源码会根据 sign item type 给元素挂不同处理：
- 日期字段可自动填今天
- text / textarea 可在 focus 时写入 auto value
- signature / initial 会触发签名对话框
- radio 要维护整组选择状态
- selection 要同步内部值和 UI class
- strikethrough 需要维护特殊状态值
这说明 Sign 前端的核心不是“画控件”，而是给每种签署项建立合适的行为语义。
三、导航器的价值，是把“下一步该签哪里”变成显式引导
startSignItemNavigator() 会找出尚未完成的签署项，按页码、Y、X 顺序排序，再自动滚动到下一个待签点。这个机制非常产品化，因为真实用户并不擅长在长 PDF 上自己找空位。
换句话说，导航器不是锦上添花，而是 Sign 可用性的关键组成部分。
四、签名对话框不是收集图片，而是在维护用户签名资产
当用户点 signature / initial 时，系统不只是弹一个画板。对话框还要处理：
- 当前 signer 名称
- 是否有已有签名图像
- frame/边框图像
- 是否更新用户自己的默认签名资产
- 自动签名与手动签名的切换
因此签名对话框更像一个小型状态机，而不是单次输入弹窗。
五、最容易误解的地方：自动填值不等于自动完成
比如日期、文本 auto value、公司印章等，前端可以在 focus 或点击时自动填入，但真正完成状态仍要通过 checkSignItemsCompletion() 统一汇总。这是正确的，因为“字段有默认值”并不代表整个签署流程已经完成。
六、结论
Sign 前端真正厉害的地方，不在于能把签名贴到 PDF 上，而在于它在 iframe 里把定位、跳转、自动填值、签名采集、完成校验组织成了一个顺手的流程。
所以它不是“PDF + 画笔”，而是一套完整的企业级签署交互层。
DISCUSSION
评论区