service worker语法错误会导致注册失败、功能全部失效且无降级路径；需通过chrome://serviceworker-internals/定位错误，避免顶层await、正确声明模块类型、禁用document/window、确保json合法，并在构建和ci中嵌入eslint、puppeteer验证及sourcemap机制。
Service Worker 脚本一旦存在语法错误，浏览器将完全拒绝注册，导致离线缓存、消息推送、后台同步等全部功能失效，甚至影响页面关键逻辑（如依赖 SW 的 API 初始化）。这不是警告，而是硬性失败——用户刷新后依然报错，且无降级路径。
快速定位语法错误位置
不要依赖控制台“空白”或“无报错”的假象。需主动打开 Chrome 的 Service Worker 专用调试入口：
- 访问 chrome://serviceworker-internals/，找到你的站点，点击“Inspect”打开独立 DevTools 窗口
- 切换到 Console 面板，此处会显示 脚本解析阶段的原始语法错误（比如
Unexpected token '}'），比页面主控制台更早、更准确 - 若该页面未列出你的 SW，说明注册根本未触发，问题出在注册调用前（如
navigator.serviceWorker.register()所在 JS 报错）
修复语法错误的实操要点
常见却容易被忽略的陷阱：
-
顶层 await 不被允许：Service Worker 全局作用域不支持顶层 await。写
const data = await fetch(...)会直接报错。必须包裹在事件监听器内（如install或fetch中） -
模块语法需显式声明：若使用
import/export，必须在register()时传入{ type: 'module' }，且确保服务器返回正确的 MIME 类型（application/javascript+module） -
不能使用 document 或 window：SW 运行在独立线程，访问这些对象会抛
ReferenceError。检查是否误写了document.querySelector或window.location -
JSON 字符串必须严格合法：多一个逗号、少一个引号、用了单引号代替双引号，都会让整个脚本加载失败。建议用
JSON.parse()前先校验字符串
防止错误上线的防御机制
靠人工检查不可靠，必须嵌入构建与发布流程：
- 在构建脚本中加入
eslint --ext .js sw.js，启用eslint-plugin-service-worker规则集，自动拦截localStorage、document等非法调用 - CI 流程中增加运行时验证：用 Puppeteer 启动无头 Chrome，执行
navigator.serviceWorker.register()，捕获catch中的 error.message 并阻断发布 - 为 SW 文件配置独立 sourcemap，并在 manifest.json 的
background.service_worker指向带 hash 的文件名（如sw.abc123.js），避免旧缓存干扰新版本验证
语法错误不是小问题，它是 Service Worker 的第一道生死线。一次失误，全站离线能力归零。把验证左移到编辑器保存时、构建阶段和 CI 流水线里，比上线后再排查快十倍。
