把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 Wake Lock 只阻止屏幕自动关闭，不保证网络或 Service Worker 存活。浏览器在页面隐藏或系统策略变化时可随时释放 sentinel。
离线体验必须诚实区分本地可用、等待同步和服务端已确认。缓存版本、命令队列和冲突解决要一起设计，否则重新联网只会放大旧操作与新事实的冲突。
落地方案的关键部件
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 仅在前台大文件或正在观看屏幕且用户启用时申请，监听 release 更新 UI；回到前台若任务仍活跃可在用户偏好下重新申请。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“Screen Wake Lock：长传输防休眠，也要在隐藏和结束时释放”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
别让错误假设进入生产
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 页面加载即申请会浪费电且常被拒绝；任务结束未 release 会让手机一直亮屏，用户以为应用失控。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
发布闸门应该检查什么
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 测试授权/拒绝、隐藏恢复、系统强制释放、低电量、任务完成/取消和多任务引用计数，最终 lock 数必须归零。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。