好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 push subscription 是浏览器服务端点与密钥集合，不是永久用户 ID。端点会轮换或返回 404/410，服务端应停止发送并让客户端重新登记。
离线体验必须诚实区分本地可用、等待同步和服务端已确认。缓存版本、命令队列和冲突解决要一起设计，否则重新联网只会放大旧操作与新事实的冲突。
先定义系统契约
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 只在明确价值场景请求权限，订阅绑定设备与偏好；payload 只含事件 ID 和最小类别，Worker 打开已验证路由后再取内容。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“Web Push 生命周期：订阅会失效，权限也会改变”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 首次加载弹权限提示会导致永久拒绝；push payload 带消息正文会暴露给推送基础设施和系统通知历史。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 没有背压或配额时，慢消费者会把内存、队列长度与尾延迟一起推高，最后拖累无关用户。
如何逐条验证契约
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 覆盖 allow/deny/default、端点轮换、410、多设备关闭、VAPID 轮换和重复 push，通知一次、内容最小且偏好生效。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。