【标题】测试 webframe：这个 5MB 的爬虫工具，真能替代浏览器自动化吗？
【摘要】webframe 通过复用系统内置 Webview 实现了极致轻量化，但评估发现其在内存占用、网络沙箱隔离及生产级任务兼容性上存在明显短板，目前更像极客玩具。
【正文】
浏览器自动化的世界里，Playwright 和 Selenium 几乎是统治级的存在。它们的功能确实强大，但代价往往是一套臃肿的浏览器二进制文件。于是，开发者 Jeff Lindsay 提出了一个颇有吸引力的设想。如果能直接复用操作系统自带的 Web 引擎（如 macOS 的 WKWebView 或 Windows 的 WebView2），是不是就能把这个笨重的大家伙瘦身成一个几兆大小的精巧程序。
这就是 webframe 的起点。它宣称能像运行脚本一样运行网页，将网页输出直接映射到终端，听起来既极客又高效。但当我们把这套方案放到生产环境的试炼场中时，数据却给出了冷静的反馈。
性能的轻量陷阱
表面看，webframe 的原生可执行文件仅有 5MB 多，对比动辄百兆的浏览器依赖，简直是优雅的代名词。然而，一旦进入运行态，内存占用（RSS）直接冲到了 640 MB，甚至高于使用 Chrome 的 shot-scraper 方案。
在 Linux 环境下，由于 WebKitGTK 依赖的强制捆绑，Docker 镜像体积甚至会膨胀到 580 MB。这种安装时轻便、运行时臃肿的反差，揭示了复用系统 Webview 的本质矛盾。你省下的只是下载带宽，但并没有真正优化运行时架构对系统资源的调用逻辑。
生产级任务的缺位
作为爬虫工具，webframe 目前表现得非常天真。最核心的缺陷在于，它无法获取 HTTP 响应状态码及 Header 信息。对于任何需要处理反爬、鉴权或根据状态码做异常捕获的生产任务而言，这几乎是硬伤。
此外，它对网页的行为管控依然很弱。由于是调用原生 Webview，它严格遵循网页的 CSP（内容安全策略），这导致它在执行复杂的 JavaScript 脚本时，极易被拦截，不像全功能浏览器那样能够通过 API 注入进行灵活的绕过或修改。
安全边界的虚实
大家对 webframe 的另一个期待是沙箱。Jeff Lindsay 的设计思路是让网页在受限的 Webview 环境中执行，但深入评估显示，这种隔离极其脆弱。
- 风险.环境变量直接被暴露为页面的全局变量，敏感信息存在泄露隐患；且研究发现，现有的简单容器化（如 Bubblewrap）无法有效封堵 WebKit 进程的网络请求，其作为不可信代码执行环境的安全性未经工业验证。
为什么它目前只是玩具
如果你追求的是某种极简主义的胜利，webframe 提供了一种有趣的架构视角，即利用系统原生组件减少冗余。但从工程实践的角度看，它目前处于一个尴尬位置。它既没有达到传统自动化工具的控制颗粒度，也没有在资源开销上实现真正的瘦身。
历史上的技术变迁往往遵循天下熙熙，皆为利来的逻辑，极致的工程优化通常源于极高的商业投入。这种小众的开源实验，虽然为我们展示了绕过重型二进制环境的思路，但要在爬虫、沙箱等领域真正取代成熟的工业级方案，它还需要解决那些枯燥但致命的工程底层难题。
【锐评】所谓极简往往伴随着隐形成本，工业级应用从来不相信“轻量”的捷径。