2026 年 4 月 20 日，开发者 Joshua Blais 公布了一项反常识的日常实验，他将 GNU Emacs 编辑器内置的文本浏览器 EWW（Emacs Web Wowser）设为桌面与手机端的主力浏览器，并表示这套方案满足了自己 85-90% 的日常上网需求。哪怕在移动设备上，他也通过 Termux 运行 Emacs 和 EWW，仅在 5-10% 的场景下回退到手机端的 Fennec 或桌面端的 Chromium。这并非因为诞生于 Emacs 24.4 时代的 EWW 突然攻克了现代复杂前端，而是他通过 客户端能力降级 与协议分流，在本地重建了一道过滤算法噪音的物理网关。
85-90% 可用率背后的幸存者偏差
初看 Blais 的描述，很容易误以为 EWW 已经强大到能直接对抗 JavaScript 泛滥的现代互联网。但翻开 GNU Emacs 官方手册就会发现，EWW 底层依赖 Simple HTML Renderer（shr）直接将 HTML 解析渲染到编辑器缓冲区内，原生零 JavaScript 支持。
它之所以能撑起 85-90% 的日常需求，是因为作者先对自己的上网定义动了手术。在他的完整工作流里，日常浏览被严格收敛为信息检索、查阅技术文档和阅读独立博客；至于在线网银、政府表单、客户门户网站，以及依赖 JavaScript 的 X（原 Twitter）和 YouTube 网页端，则被他直接排除在 EWW 的日常任务之外。
这种先砍需求再谈兼容的做法，在 Hacker News 社区（讨论帖 ID 50507553）引发了激烈交锋。支持者视之为高信噪比的数字极简主义，正如 Blais 所言，现代浏览器与 Discord 等封闭前端构成了互联网的第八层（Layer 8），用无限滚动的推荐流绑架了深度思考；而评论者 Arubis 则指出，EWW 仅对静态 HTML 表现良好，面对绝大部分商业网站寸步难行，另一位网友 ohaodha 更直言，靠刻意制造使用障碍来减少分心，很难算得上软件本身的优势。
不是 EWW 兼容了现代互联网，而是极客主动戒断了商业前端。
- 提醒.对于每天必须处理飞书文档、在线政务、企业级 SaaS 协作或频繁切换账号的普通职场人，强行套用 EWW 只会带来严重的工作流断裂。
用路由网关拆解全能浏览器
如果只把 EWW 当成一个残缺的网页阅读器，就漏掉了这套方案在架构上的精妙之处。Blais 在自己的 browser.el 配置文件中，利用 Emacs 的 browse-url-handlers 变量做了一层 正则路由分流，把现代全能浏览器大包大揽的职责拆解给了本地专用程序。
当他在自建或公共 Searx 隐私搜索实例（如 https://searx.labrynth.org/search?q=）中检索并点开链接时，Emacs 扮演的是调度器角色。遇到 YouTube、Vimeo、Twitch 或 .mp4 直链，系统直接拉起本地 mpv 播放器流式播放，绕开网页端臃肿的评论区与算法推荐；遇到 .pdf 链接，自动下载至临时文件并用内置的 pdf-tools 打开；遇到属于小型网络（Smolweb）的 gemini:// 或 gopher:// 协议，则转交 elpher 插件处理。
留给 EWW 处理的只剩普通 HTML 页面，此时按 R 键即可触发 eww-readable（类似 Firefox 的阅读模式），一键剔除页头页脚与导航栏噪音，遇到死活无法渲染的动态页面，再按 & 键（对应 eww-browse-with-external-browser）抛给备用的 Chromium。
不过照搬这套配置的新手需要注意两处细节差异。首先，EWW 并非完全无状态，它通过 Emacs 的 URL 包支持 Cookie 管理（按 C 键查看），图像请求的 Cookie 策略由 shr-cookie-policy 控制（默认值为 same-origin），但浏览历史在退出时默认丢失，若开启了桌面保存，需调整默认值为 nil 的 eww-restore-desktop 变量来控制恢复缓冲区时是否重新加载页面。其次，Blais 在文中提到的按 b 后退、按 a 加书签属于他的私人改键（分别绑定了 eww-back-url 和 eww-add-bookmark）；在 GNU Emacs 官方原生默认键位中，后退是 l 键，添加书签是 b 键，查看书签列表才是 B 键。
终端浏览器的真假极简分野
为了照顾非 Emacs 用户，Blais 在文中顺手推荐了 Lynx 和 Browsh 作为终端浏览器的平替方案。但从技术底座来看，把这三者归为一谈掩盖了核心的 反算法机制差异。
| 浏览器方案 | 底层渲染引擎 | JavaScript 支持 | 视觉与交互形态 | 防沉迷与隔离本质 |
|---|---|---|---|---|
| EWW | Emacs 内置 shr | 不支持 | 编辑器缓冲区（支持内嵌图片/GIF） | 物理切断脚本与追踪器 |
| Lynx | 纯文本解析器 | 不支持 | 纯字符单元格（无原生标签页） | 极度克制的纯文本阅读 |
| Browsh | 无头 Firefox | 完整支持 | 终端字符网格像素化渲染 | 仅降低视觉画质，未切断算法 |
Lynx 与 EWW 属于同一阵营，采用纯字符单元格界面，连原生标签页都没有，从根源上拒绝执行任何客户端脚本。而 Browsh 的底层实际在后台运行着一个完整的 无头 Firefox（headless Firefox），它具备现代 Web 的全套渲染与 JavaScript 执行能力，只是把渲染出来的画面压成终端字符网格展示出来。
用 Browsh 上网，受限的只是粗糙的字符画质、笨拙的输入定位以及像素布局与终端网格的冲突，商业网站的追踪脚本与动态信息流依然在后台全速运转。真正帮 Blais 找回专注力的，从来不是黑底白字的复古终端外观，而是 EWW 对 JavaScript 运行时的直接拔线。
- 结论.对于被信息流裹挟的知识工作者，与其考验意志力去装各种防沉迷插件，不如在阅读长文和查文档时切回只解析语义化 HTML 的轻量阅读器；而对独立博客作者与前端开发者而言，这类极简客户端在 2026 年的回潮，也再次证明了不依赖重度客户端渲染（CSR）的纯文本与静态网页，依然握有跨越周期的生命力。