非全HTTPS WebApp中能否注册Service Worker实现Firebase Webpush？

首先直接给你明确结论：你可以在HTTPS页面注册Service Worker，同时保留网站其他部分为HTTP，但存在关键的功能限制，下面详细拆解规则和注意事项：

核心规则梳理 #

• 注册Service Worker的页面必须是HTTPS（localhost开发环境除外）：浏览器的安全机制只允许在「安全上下文」（HTTPS）中调用navigator.serviceWorker.register()方法。HTTP页面根本无法触发Service Worker的注册动作，这是硬性要求。
• Service Worker只能控制同安全上下文的页面：HTTP和HTTPS属于不同的源（源由协议+域名+端口组成），所以你在HTTPS页面注册的Service Worker，只能接管同域名下的HTTPS页面，无法作用于HTTP页面。
• Service Worker脚本本身必须通过HTTPS提供：这是W3C规范的明确要求，目的是防止脚本在传输过程中被篡改，不管注册页面是什么协议，加载Service Worker的请求必须是HTTPS。

对你的场景的影响 #

如果你的Web App是混合HTTP/HTTPS架构，那么：

• 你可以在HTTPS页面成功完成Service Worker的注册，也能正常集成Firebase Webpush的订阅、接收逻辑——只要用户停留在HTTPS页面，推送功能完全正常。
• 但HTTP页面无法享受Service Worker的任何能力：用户在HTTP页面时，无法触发推送订阅，也无法被已注册的Service Worker接管；即使用户之前在HTTPS页面订阅了推送，通知会在浏览器后台弹出，但HTTP页面无法和Service Worker做交互（比如点击通知跳转到HTTPS页面是可行的，但HTTP页面内无法监听通知事件）。

关于规范的补充说明 #

早期W3C规范讨论中确实有过「全站HTTPS」的提议，但最终定稿的规范并没有强制要求全站HTTPS，而是聚焦在Service Worker的注册环境和脚本传输的安全性上。不过由于作用域的限制，非HTTPS页面无法被Service Worker控制，所以如果你的推送通知需要覆盖全站用户，还是建议逐步迁移到全站HTTPS——这不仅是Service Worker的要求，也是现代Web应用安全性的最佳实践。

Firebase Webpush的额外提示 #

Firebase的推送服务本身依赖安全上下文完成订阅流程（比如获取VAPID密钥、生成订阅对象等），所以订阅操作只能在HTTPS页面完成。一旦用户完成订阅，即使后续访问HTTP页面，浏览器后台依然能接收推送通知（因为Service Worker在HTTPS的安全上下文后台运行），但交互体验会受限。

内容的提问来源于stack exchange，提问作者VictorGalisson