Dillo 3.3.0 发布：小浏览器没变大，但把控制权递回来了

Dillo 3.3.0 的反常点很明确：它没有追着 Chrome 补功能，也没有把自己包装成现代 Web 的万能入口。

这个 2026-04-26 发布的版本，真正加的是“手柄”。命令行能控制浏览器，右键菜单能跑脚本，外部工具抓到的 HTML 能再喂回 Dillo。小浏览器没变大，但可控性变强了。

Dillo 3.3.0 到底更新了什么

这次更新可以压成一张表。

dilloc 是这次最实用的新增项。它可以通过 DILLO_PID 指定 Dillo 进程；如果系统里只有一个 Dillo 进程，也可以直接控制。

它能做的事很具体：打开 URL、刷新页面、退出浏览器、导出页面内容、打印当前 URL、标题和 HTTP 头。也能等待页面加载完成，再把标准输入里的 HTML load 到当前标签页。

page_action 更像一个网页右键菜单里的脚本钩子。用户可以在 ~/.dillo/dillorc 里配置动作。典型例子是：对当前 URL 调用 curl impersonate，模拟 Chrome 请求，绕过部分 JS wall，再把拿到的 HTML 管道回 Dillo。

这句话要收紧理解。它只能绕过部分 JS wall，不是通用反封锁工具，也不会让 Dillo 突然完整兼容现代 Web。

对 Linux/Unix 桌面用户来说，现实用法不是“换主力浏览器”。更像是把 Dillo 放进一个轻量工作流：读文档、看静态页面、抓取可读 HTML、用脚本补一点站点兼容性。

有意思的是控制权，不是功能表

现在的大浏览器，早就不只是“看网页的软件”。它们还是账号入口、同步服务、扩展平台、广告系统、支付通道，甚至 AI 入口。

Dillo 的方向相反。它承认自己小，功能有限，也不装成全能平台。

但 3.3.0 把“有限”变得更可操作。你不能指望它跑完整现代 Web，却可以用 dilloc 和 page_action 接管一部分流程。

这就是它的价值。

大浏览器给用户的是默认可用。代价是很多细节被封进黑箱：请求怎么发，cookie 怎么放，页面失败时能不能换一种方式拿内容，用户通常没有太多余地。

Dillo 给的是另一种旧式答案：接口露出来，脚本接上去，能修多少算多少。

Unix 那句老话是 “do one thing well”。放到这里，不是怀旧口号，而是路线差异。Dillo 不想吞掉用户的工作流，它愿意被用户的工作流吞掉。

这对两类人最有意义。

一类是轻量浏览器爱好者。可以升级后重点试 dilloc 和 page_action，看看常用站点能不能被脚本补出更稳定的阅读路径。

另一类是开发者和 Unix 桌面用户。Dillo 现在更适合嵌进脚本、测试、文档阅读、自动化查看这类小场景。它不是办公主力，却能当一个可控的网页组件。

普通用户不该被误导。要是日常依赖网银、企业后台、复杂 SaaS、视频站和重 JavaScript 应用，Dillo 3.3.0 仍然不适合当主浏览器。

边界很清楚：实验、妥协，以及接下来该看什么

FLTK 1.4 支持必须按实验性理解。项目要求通过 --enable-experimental-fltk 开启，维护者不应默认给所有用户打开。

原因不是保守，而是渲染问题还没收完。在 X11、96 DPI 屏幕上，FLTK 1.4.5 的渲染质量接近 FLTK 1.3；但在高 DPI，尤其不是 96 的整数倍时，以及 Wayland 场景下，仍有问题。

所以发行版维护者现在更适合观望。可以打包测试分支，可以让高级用户手动开启，但不该急着把 FLTK 1.4 设成默认。

OAuth 修复也不是“大幅放宽 cookie”。Dillo 原本默认阻止非用户发起请求带来的第三方 cookie，目的很明确：挡住图片像素一类追踪。

这次调整，是允许用户发起的主页面重定向响应设置 cookie。换句话说，用户点了登录，OAuth 的主流程需要 cookie，Dillo 给它开一个窄口。

这个处理比较克制。太严，登录坏；太松，追踪回流。Dillo 选择的是修 OAuth，而不是把反追踪边界整体拆掉。

还有一个小变化也能看出项目气质：Dillo 已经从 GitHub 迁到自托管 cgit，并镜像到 Codeberg 和 SourceHut。别把它读成项目规模扩大，也别读成商业化信号。

更准确的说法是：这个小项目在继续掌控自己的基础设施。

接下来最该看三件事。

Dillo 3.3.0 不会改变浏览器市场。它也不是给大众用户准备的反击剧本。

它更像一次提醒：浏览器不必只剩巨型平台和废弃玩具两种形态。中间还有一条窄路，叫可修补的个人工具。

这条路不宽，但有门把手。对厌倦网页膨胀的人来说，这已经很难得。