WhatsApp 静音还是屏蔽?共享收件箱的操作选择
只想减少 WhatsApp 通知干扰,应选择会话静音;希望阻止某个人向账号发消息,才考虑屏蔽联系人。两者都不能代替系统内部的“暂停自动回复”或“工单已解决”。共享收件箱应把这些决定分开,避免为了安静而切断客户联系,或者以为静音后 AI 就不会继续回复。
三种控制,三种目的
WhatsApp 通知指南将静音作为聊天通知设置。屏蔽指南说明,被屏蔽的联系人无法再给你打电话或发送消息;解除屏蔽后,也不会收到对方在屏蔽期间发送的消息。因此,屏蔽不是可以稍后恢复消费的消息缓冲区。
| 目的 | 应选控制 | 不能据此推断 |
|---|---|---|
| 减少聊天通知干扰 | 会话静音 | 工单已解决,或 webhook 收件已关闭 |
| 阻止特定联系人联系 | 经授权确认后屏蔽联系人 | 历史内容已删除,或解除后会补回消息 |
| 暂停 AI 自动回复 | 应用自己维护的自动化暂停状态 | 平台静音或屏蔽会取消本地队列任务 |
| 保留后续跟进事项 | 本地工单状态,必要时辅以未读标记 | 未读等于静音 |
后两项是应用设计建议,不是新增的 WhatsApp API 功能。已读相关边界可参阅WhatsApp 已读与未读同步指南。通知偏好、阅读回执和团队任务分配解决的是不同问题。
UnifyPort 实际提供哪些操作
UnifyPort 的非官方接口把会话操作和联系人操作分开。下表描述的是 UnifyPort 契约,不是 Meta Cloud API 路由。
| 操作 | 输入及文档边界 | 参考 |
|---|---|---|
| 静音 | conversation_id,加秒数 duration 或未来的 RFC3339 时间 mute_until;两者不能同时传 | 静音会话 |
| 取消静音 | conversation_id | 取消会话静音 |
| 屏蔽或解除屏蔽 | contact_id,必须是 digits@lid 形式的 WhatsApp 规范 LID | 屏蔽联系人与解除屏蔽 |
| 查看屏蔽列表 | 返回 data.blocklist 和列表指纹 data.dhash | 获取黑名单 |
静音参数 duration: 0 表示永久静音,不是关闭静音。恢复通知应调用明确的取消静音操作。
展示按钮前,先查看平台操作支持矩阵。当前文档将屏蔽、解除屏蔽和黑名单读取映射到 WhatsApp;静音支持 WhatsApp,LINE 为部分支持,取消静音也映射到 LINE。统一路由不意味着所有平台行为一致;不支持的组合返回 501 unsupported_by_provider。
不要自行拼造屏蔽标识
WhatsApp 屏蔽和解除屏蔽操作不接受手机号或 @s.whatsapp.net JID 来替代规范 LID。应通过文档中的联系人流程取得实际标识,不能给手机号拼上 @lid 就认为指向同一个人。
联系人响应可能包含不同的 id、provider_user_id 和 conversation_id,保存时应保留各自含义。联系人 API 与 vCard 指南也解释了修改通讯录与发送联系人资料为何属于不同操作。本文并不是要求你为了屏蔽某人先把对方添加为联系人。
先设计收件箱决策,再调用接口
假设客服队列不断收到重复消息:如果仍需要审核这些内容,静音可以处理通知干扰,本地暂停状态可以阻止不合适的 AI 回复。如果有权限的审核人员决定屏蔽联系人,应把它作为另一项明确操作。
建议采用以下应用流程:
- 清楚命名。 分开显示“静音通知”“屏蔽联系人”和“暂停自动回复”,并限定所选消息账号及目标。
- 确认身份。 屏蔽必须使用与该账号对应、已核实的规范 LID。身份不确定时停止并交给人工,而不是猜测。
- 本地记录意图。 保存操作人、原因、目标和请求的操作。这些是应用审计记录,不是应额外塞进 API 的字段。
- 检查结果。 文档中的变更响应包含
data.ok。不能仅因点击按钮就显示成功;保留脱敏错误与request_id便于排查。 - 核对不确定结果。 屏蔽或解除屏蔽请求超时后,先读取黑名单再考虑下一次变更。按一致规则比较标识;
dhash能提示列表变化,但不能说明是谁、为何修改。 - 单独处理排队中的自动化。 决策前创建的任务可能仍在数据库里。发送前让工作进程检查本地暂停策略,不能把平台设置当作自己的队列取消机制。
对于静音变更,事件参考记录了 conversation.updated 以及 muted、mute_until 等设置。收到事件时可作为状态观察,但不要保证每次操作都有对应确认。公开事件目录未记录联系人屏蔽事件,应使用已文档化的黑名单查询,而不是自行假设事件存在。
验收检查与限制
使用自己控制的账号测试:界面应区分变更失败与已生效;取消静音不能调用解除屏蔽;解除屏蔽不能自动放行旧回复任务。还应测试标识被拒绝和超时后结果不明的情况。这些是建议测试,不是已完成的测试结果。
不要用静音控制 webhook 流量。静音接口改变会话状态,文档没有说它会关闭事件投递。同样,本文不承诺屏蔽会删除已保存内容、管理共同群组,或取消 CRM 中的任务,这些都应单独定义。
如果原生应用内的人工操作已经足够,直接使用原生控制即可。如果需要官方商业集成,应独立评估其契约,不要把这些 UnifyPort 路由当成 WhatsApp 官方接口。
常见问题
静音聊天会停止自动回复吗?
不能这样假设。应由回复工作进程检查明确的本地暂停状态;静音没有被文档定义为取消任务的操作。
可以使用手机号 JID 屏蔽联系人吗?
UnifyPort 的 WhatsApp 屏蔽操作不可以。必须使用规范 digits@lid,而非手机号或 @s.whatsapp.net 值。
解除屏蔽后会补收屏蔽期间的消息吗?
不会。WhatsApp 官方帮助明确说明不会补收,因此不要把屏蔽设计成可恢复的消息缓冲区。
dhash 变化能证明我的操作成功吗?
不能单独证明。它是整个黑名单的指纹,应检查目标联系人是否存在,并单独保留操作结果。
下一步与参考资料
先阅读屏蔽联系人参考,确认标识映射后,再在共享收件箱启用按钮。
核对日期:2026-09-25。
让消息接入变成一条稳定的产品管线。
先用统一 API 跑通发送,再用标准事件把所有入站消息接回业务系统。