网页推送最容易被误解成“给所有访问过网站的人群发一条通知”。但 enterprise/social_push_notifications/models/social_live_post.py、social_account.py 和 website_visitor.py 其实在做一件更谨慎的事：先筛真正可触达的访客，再按时区批次发送，发送时还要在 Firebase 配置和 IAP 通道之间兜底，最后把失效 token 清掉。
一、Push post 不是普通社媒帖子，它要先走专门投递逻辑
social_push_notifications 对 social.live.post 做了扩展，核心方法是 _post() 和 _post_push_notifications()。这意味着网页推送虽然挂在 Social 应用下，但它并不复用普通社媒发帖的心智，而是有一条单独的投递流水线。
业务上这很合理：微博、LinkedIn、Facebook 面向的是平台账号；网页推送面向的是你自己站点上的 visitor 订阅关系，数据边界完全不同。
二、访客筛选不是按“全部订阅用户”，而是考虑时区和活跃性
social_live_post.py 里定义了 get_filtered_timezone_visitors(visitor)，website_visitor.py 又提供 _inactive_visitors_domain()。这说明 Odoo 在做网页推送时，首先关心的不是名单越大越好，而是“这个访客在当前时区、当前活跃状态下，是不是值得现在推”。
这点非常企业化。跨时区站点如果不分批，亚洲凌晨和欧美工作时段会被一锅端；长期不活跃的订阅者继续推，也只会拉高失败和退订。
三、Firebase 不是唯一通道，系统准备了 fallback
social_account.py 里同时有 _firebase_send_message()、_firebase_send_message_from_configuration() 和 _firebase_send_message_from_iap()。这表示官方默认承认两件事：
- 企业可能自己配好了 Firebase；
- 企业也可能需要通过 IAP 或托管方式兜底。
所以推送体系不是“有没有 Firebase 就结束”，而是“先判断当前可用发送路径，再选择最合适的那条”。
四、token 清理是主链路的一部分，不是后期卫生工作
_clean_unregistered_tokens() 和 website_visitor._register_push_subscription() 放在同一模块里，透露出很明确的设计：注册订阅和清理失效订阅同样重要。如果一条 token 已经无效，还继续保留在 visitor 侧，后续每次推送都会浪费请求并污染成功率统计。
这也是为什么企业做网页推送时不能只看“注册量”，还要持续看“活跃订阅量”。
五、实战注意事项
- 先把 visitor 订阅质量看清楚：不是有 token 就等于有效用户。
- 按时区投递：跨区域站点尤其要避免单批群发。
- 把 Firebase fallback 作为正式设计：外部通道出故障时必须有兜底路径。
- 定期清理无效 token：否则投递成功率和用户画像都会失真。
新手误区
- 误以为网页推送和普通社媒发帖是同一类对象。
- 误以为订阅人数越多越好，不必关心活跃度和时区。
- 误以为 Firebase 配好后就没有运营问题。
- 误以为 token 清理只是系统维护，不影响业务效果。
主要源码参考
enterprise/social_push_notifications/models/social_live_post.pyenterprise/social_push_notifications/models/social_account.pyenterprise/social_push_notifications/models/website_visitor.py
DISCUSSION
评论区