很多团队第一次听到 WhatsApp 签署，会觉得这无非是“把 sign link 换个发送渠道”。但 enterprise/whatsapp_sign/models/sign_request.py 和 sign_request_item.py 说明，真正难的不是发出去，而是：模板是否合规、签署对象有没有手机号、哪些字段允许注入模板、完成和拒签后如何回执。
一、发送渠道先过配置校验，不满足就不让建单
sign_request.py 的 _check_send_channel() 会先调用 sign.request.item._check_whatsapp_template_exists()，要求访问模板、完成模板、拒签模板三套配置都存在。只要选择 send_channel == 'whatsapp' 而模板缺失，就直接抛出校验错误。
这说明官方并不把 WhatsApp 当成“可选通知层”，而是当成一条需要完整配置的业务通道。缺模板时勉强发出，后面完成通知和拒签通知都会断链。
二、签署人手机号是硬门槛，不是提醒项
_check_partner_id() 明确要求：若签署请求走 WhatsApp，签署人的 partner_id.phone 不能为空。没有手机号直接报错，而不是给个黄色 warning。
这样做很合理。电子签署的消息链路一旦切到 WhatsApp，手机号就不是“补充资料”，而是主要寻址方式。晚一点再补，意味着整条签署任务都没法稳定送达。
三、模板变量不是随便拼字段，要走安全白名单
_get_whatsapp_safe_fields() 只开放少量安全字段，例如签署人手机号、显示名、请求参考号、签署链接、附件下载链接、签署人列表、拒签原因等。这个白名单思路特别重要：企业常常想把更多业务字段塞进消息模板，但 WhatsApp 模板一旦过度注入，就可能把内部信息暴露给外部签署人。
所以这里的关键不是“模板能不能更灵活”，而是“哪些字段值得被安全地外发”。
四、真正的签署链接是按 request item 逐个生成的
_send_signature_access_message() 在 WhatsApp 模式下会为每个 sign_request_item 生成独立链接，并写回 sign_link，再用配置好的模板发消息。这说明一份 sign request 虽然是业务上的整体，但消息投递和链接访问仍然是以 signer 为粒度管理的。
对企业来说，这意味着提醒、追踪、拒签、下载附件这些动作，最终都要回到“某个签署人是否被正确路由”上，而不是只看整单状态。
五、完成与拒签消息并不是附带功能，而是闭环的一部分
_send_completed_documents_message() 与 _send_refused_message() 会优先尝试走 WhatsApp；如果发现模板缺失等配置问题，再回退到 email。这个回退设计很务实：它承认外部消息通道会出问题，但不能让签署闭环因此消失。
也就是说，WhatsApp 集成不是把 Email 替换掉，而是把签署通知主通道前移，同时保留兜底。
实战注意事项
- 三套模板一起验收：发起、完成、拒签缺一不可。
- 手机号先治理，再开通渠道：不要把联系人数据治理推到项目后期。
- 模板字段越少越好：白名单本来就是为了控制泄露面。
- 保留 Email fallback：外部通道再顺畅，也不该成为唯一出口。
新手误区
- 误以为 WhatsApp 签署只是换个发送按钮。
- 误以为没有手机号也能先建请求、后续再补。
- 误以为模板变量可以直接引用任意业务字段。
- 误以为签署完成后的通知不重要。
主要源码参考
enterprise/whatsapp_sign/models/sign_request.pyenterprise/whatsapp_sign/models/sign_request_item.py
DISCUSSION
评论区