先说结论
一封管理摘要能不能长期被人接受，关键不在它能不能发，而在它会不会越发越烦。Odoo 在 Digest 里用 one-click 退订、自动降频和偏好入口做了三道减压阀，目的就是让“管理摘要”别滑向“系统骚扰”。
第一层：one-click 退订为什么不是一个普通链接
_get_unsubscribe_token() 会基于 digest 和 user 生成 HMAC 令牌，_action_send_to_user() 再把它放进 List-Unsubscribe 与 List-Unsubscribe-Post 头里。这不是页面装饰，而是让邮件客户端能把退订动作识别成标准能力。也就是说，Digest 的退订不是“跳去某个页面再点一次”，而是尽量做到邮件层就能完成。
第二层：为什么 Digest 还要主动判断用户是否太久没登录
_check_daily_logs() 会根据当前 periodicity 去看用户日志：日摘要看最近 2 天，周摘要看最近 7 天，月摘要看最近 1 个月。如果没有登录痕迹，系统会把摘要列入 slowdown 集合。这背后的思路很直白：如果人都不登录系统了，还按高频发送摘要，多半只会增加噪音。
第三层：偏好入口为什么要直接写在邮件里
_compute_preferences() 会在特定条件下直接生成“切到 weekly”“打开配置页”等入口。官方没有把这些操作藏在后台，是因为 Digest 被视作一种持续性沟通产品。真正有效的邮件，不只是展示信息，还要顺手把收件人的退出、降频和自定义动作铺在眼前。
第四层：退订、降频与偏好为什么必须一起看
如果只有退订，没有自动降频，很多人会在烦到极点时才一刀切关闭；如果只有降频，没有透明偏好入口，用户又会怀疑系统在暗改设置。Odoo 把三者组合起来，本质上是在做“软退出机制”：先减少打扰，再允许明确退出，再提供显式设置。
第五层：这条链最适合防什么坑
最常见的坑就是管理摘要上线时好评，三个月后人人无视。那通常不是 KPI 写得不够炫，而是频率、退出和偏好设计得太粗糙。Digest 的这一层源码，其实就是在帮产品经理提前防这种疲劳。
最容易误解的三个点
- 误区一：能退订就说明邮件体验合格。错，用户往往更希望少一点而不是直接没了。
- 误区二：低活跃用户不重要，所以随便发。实际上这批用户最容易把摘要视作噪音。
- 误区三：偏好设置应放后台就行。对频繁邮件来说，入口离收件箱越近越好。
实战上怎么用更稳
- 如果你扩展 Digest，自定义 KPI 可以后加，但退订与偏好体验尽量别弱化。
- 做内部系统邮件时，可以直接借鉴 List-Unsubscribe 头的思路。
- 被抱怨“邮件太多”时，优先考虑降频策略，而不是马上加更多开关。
最后总结
Digest 真正成熟的地方，不是它会发摘要，而是它知道什么时候该少发、让谁能轻松退出，以及怎样把控制权还给收件人。
DISCUSSION
评论区