在电脑上双击打开一个index.html你会发现网页里不少东西突然就不工作了。Service Worker 注册不了连放在同一个文件夹里的 JSON 文件也没法通过fetch()正常读取。非会员可免费阅读。于是你还是得走那套熟悉的流程启动服务器。Firefox 153 新增的 Local Mode是我见过第一个能让这一步变成可选项的功能。就几个静态文件为什么还得开着终端遇到这种情况我的第一反应通常是运行npx serve。如果是在正式项目里我会用 Vite 开发服务器临时做个 HTML 小实验有时就直接点一下 VS Code 里 Live Server 扩展的“Go Live”。npx serve.# 或者使用 Live Server这些操作都不难。只是想在浏览器里看看一个静态文件夹却要启动进程、占用端口再多开一个大概率会忘记关闭的终端标签页多少有点折腾。举个实际点的例子假设你正在测试一个简单的商品页面文件夹里有index.html、products.json以及一段负责加载商品详情的 JavaScript。你用不上后端也不需要数据库只想看看页面能不能正确显示商品卡片。可只要代码里用了fetch(./products.json)直接打开 HTML 文件就可能请求失败。结果一个本来不需要服务器的页面为了测试还是得先启动服务器。Firefox Local Mode 想省掉的就是这点小麻烦。问题出在file://协议上。从磁盘直接打开的页面并不会获得一个普通网页那样的源也就是 origin。在我的 Firefox 中file://页面上的location.origin返回的是null。接下来凡是涉及源检查的功能都会变得格外谨慎。起初我以为更大的障碍来自“安全上下文”限制。毕竟异步 Clipboard API、摄像头访问、WebGPU 等 API通常需要 HTTPS 或 localhost 环境才能使用。但让我意外的是在 Firefox 中这个file://页面的isSecureContext居然返回了true。所以至少在 Firefox 里真正造成大部分麻烦的是那个值为null的 origin。Service Worker 的要求还要严格。Firefox 会直接拒绝它在file://下注册报错也很直白“脚本 URL 使用的协议不是 http 或 https。”一个很香的 AI 平台GPT-5.6 低倍率且不降智 和 Claude Code 4.8 只要 0.25倍率包含 image-2生图。重点是 首字请求都在 5s 内。入口https://ai.aiyuhub.comFirefox Local Mode 到底做了什么Firefox Local Mode 是一项开发者工具功能可以把磁盘上的文件夹映射到一个自定义的https://源。文件由 Firefox 自己提供因此不用额外启动服务器进程也不占用监听端口。按照 Mozilla 文档的说明它主要带来三个变化只能在安全上下文中使用的 Web API可以用本地文件进行测试。每条映射都有独立的 origin因此各个项目拥有各自的存储空间和 Cookie。映射只在 Firefox 内部生效其他程序和局域网中的其他设备都无法访问。最后一点和npx serve有明显区别。后者通常会同时显示本机地址和局域网地址而 Local Mode 没有监听端口自然也就没有一个可供其他程序或设备连接的入口。我在 Firefox Developer Edition 159 中用一个小型演示文件夹进行了测试里面只有index.html、旁边的data.json以及一个 Web Worker 脚本。这还算不上真正的项目所以下面的结果只代表我在一台 Windows 电脑、一个文件夹里的测试情况。怎么创建映射打开 DevTools进入设置面板。一条映射需要填写两项内容origin 和本地文件夹路径。Mozilla 给出的示例是把https://firefox.localhost映射到/home/alex/app。还有个更快的入口保持 DevTools 打开然后访问任意一个file://地址Firefox 就会弹出提示提供两个按钮。点击“Try it”会创建临时映射关闭 DevTools 或 Firefox 后就会消失点击“Add To Settings”则会保存为永久映射。这个临时与永久分开的设计比我预想中更实用。我打开的大部分本地 HTML 都是临时文件一个复现 bug 的例子、一个 CSS 小想法或者从 Stack Overflow 回答里拿来、还没完全确认是否靠谱的代码片段。点一下“Try it”就能测试也不会留下越来越多的配置。如果你习惯直接修改配置也可以进入about:config。每条映射都对应一组带编号的首选项两个项目的配置大致如下devtools.local-mode.mappings.0.origin firefox.localhost devtools.local-mode.mappings.0.path /home/alex/app devtools.local-mode.mappings.1.origin demo.localhost devtools.local-mode.mappings.1.path /home/alex/demo devtools.local-mode.mappings.1.disabled truedisabled是可选项。暂时不用某条映射又不想删除时加上它就很方便。实测下来哪些能用哪些没跑通点击“Try it”后我的演示页面重新加载地址变成了https://firefox.localhost/index.html。这次页面的 origin 是正常的https://firefox.localhostisSecureContext也返回了true。fetch(data.json)成功读到了旁边的文件Web Worker 也顺利启动并把消息发了回来。整个过程中我没有另外运行服务器。接着我加了一个 Service Worker结果安装失败ServiceWorker script at https://firefox.localhost/sw.js for scope https://firefox.localhost/ encountered an error during installation.我的第一反应是是不是sw.js写错了可那个文件总共就一行代码。于是我在127.0.0.1:443上启动了一个简单的监听程序再刷新页面。结果Firefox 居然尝试连接这个真实端口一共二十次。我又刷新了两次每次都是二十次。这个数字太规律了不太像偶然出现的杂音。页面自己的fetch()和 Web Worker 都能正常加载因此就我观察到的情况来看Service Worker 脚本请求似乎绕过了 Local Mode跑去连接一个并没有提供相应文件的端口。我的猜测是Local Mode 会拦截标签页发出的请求但获取 Service Worker 脚本的请求可能不属于这一类。Mozilla 文档没有明确说明是否支持 Service Worker我也没找到相关的 Bugzilla 问题记录所以不排除我漏掉了某项设置。不过至少在 Firefox 159 上我不会指望它一定能正常工作。如果你正在开发渐进式 Web 应用也就是 PWA这一点就很重要。离线页面、文件缓存以及断网后重新打开应用都可能依赖 Service Worker。每个项目一个 origin可能才是更实用的地方最吸引眼球的卖点是“不用启动服务器”但在我看来每个项目拥有独立的 origin反而更有价值。源由协议、主机名和端口共同决定。Vite 默认会尝试在localhost:5173启动项目所以当项目 A 停止、项目 B 接着使用同一端口时A 留下的localStorage、Cookie以及那个最容易惹麻烦的已注册 Service Worker可能还待在同一个源下面。如果你曾经打开一个新项目浏览器却给你显示了另一个项目的缓存页面通常就该怀疑旧的 Service Worker 了。最后你还得打开 DevTools → Application手动把它注销。换成 Local Modehttps://shop.localhost和https://blog.localhost就是两个不同的源各自使用独立的存储空间和 Cookie项目之间也就不会沿用这些旧数据。光是这份隔离能力就足以让我考虑使用它哪怕那个文件夹用普通服务器也能正常打开。但有个前提DevTools 得一直开着映射只有在 DevTools 打开时才会生效。面板一关页面也就失去了对应的映射。我猜这是有意为之目的是让 Local Mode 保持开发工具的定位。不过第一次使用时还是很容易踩坑比如换个没有打开 DevTools 的窗口重新加载页面然后纳闷刚才还好好的怎么突然全坏了那 localhost 服务器还要不要留很多时候还是得留。Local Mode 负责从磁盘加载文件不会替你执行服务端程序。只要涉及后端、API 路由或服务端渲染就仍然需要服务器。Vite 的热模块替换也就是 HMR以及 TypeScript、JSX 转换还有import react这类裸模块导入的解析都属于开发服务器的工作Local Mode 不负责处理。它只在 Firefox 中生效。同一个页面要放到 Chrome 或 Safari 里检查还是得启动平时使用的服务器。我的测试中Service Worker 没有成功运行。因此PWA 和离线功能的开发测试暂时仍然需要 localhost 服务器。它更适合那些小任务纯 HTML/CSS/JS 文件夹、复现 bug 的页面、需要通过fetch()读取本地 JSON 或启动 Web Worker 的示例以及那些你只想打开看看、不想再记端口号的演示。我还不确定它最后能不能取代我日常使用的npx serve。但对于那些为了几个静态文件而临时启动服务器的场景它确实有机会。哪些人值得试一试如果你经常处理需要正常 origin 的静态文件而且本来就在用 Firefox可以先创建一条映射看看少开一个终端标签页之后自己会不会想念它。建议给每个项目分配不同的.localhost域名让存储空间保持隔离。至于涉及构建步骤、后端、Service Worker或者需要在另一款浏览器里测试的项目开发服务器还是继续留着。测试时我也遇到了这些问题为什么有些浏览器 API 在 file:// 下会失败在我的 Firefox 测试中直接从磁盘打开的页面其 origin 为null。因此读取同一文件夹中文件的fetch()请求会被拦截Firefox 将其报告为 CORS 错误加载 Web Worker 脚本也会遇到安全限制。Service Worker 则直接拒绝使用 http、https 之外的协议。Firefox Local Mode 为文件提供了正常的https://源在我的测试中解决了 fetch 和 Web Worker 的问题但没有解决 Service Worker 的问题。没有 HTTPS怎么在本地测试 Service Worker在 localhost 上启动一个普通 HTTP 服务器就可以。浏览器会将http://localhost视为安全上下文因此不需要额外配置证书。不过我测试的 Firefox Local Mode 没能完成这件事在 Firefox 159 中Service Worker 的脚本请求似乎绕过了映射最终导致安装失败。做前端测试还需要 localhost 服务器吗如果是框架项目、带后端的项目或者需要在其他浏览器中测试答案仍然是需要。对于只在 Firefox 中查看的普通静态文件Local Mode 可以承担这部分工作。npx serve还在我的命令历史里。做完那轮 Service Worker 测试后我更确定暂时不能把它扔掉。但下一次一个静态文件夹只是需要正常的 origin 时我会先试试 Firefox Local Mode再决定要不要打开新的终端。