Mac 用户的浏览器困境，是一个不可能三角：要性能就装 Safari，要扩展就装 Chrome，要两者兼得就得忍受 2GB 内存。
2026 年 10 月，一个 6MB 的 macOS 浏览器 Search 开源了。它直接调用系统自带的 WebKit 内核——和 Safari 同一颗心脏——却宣布支持 Chrome 扩展。不是"部分支持"，是从 Chrome Web Store 直接拉取、校验 CRX3 签名、注入 shim 补 API 的完整链路。
作者 driceroland（Office Commun）在 9 月 20 日放出首版。小众软件 10 月 3 日推荐。我把它拆开看了看，发现真正有意思的不是"6MB"这个数字，而是它怎么把 WebKit 的扩展短板一层层补上的。
TL;DR
- Search 是仅 6MB 的 macOS 开源浏览器，直接调用系统 WebKit 内核，性能看齐 Safari
- 通过 WKWebExtension + CRX3 签名校验 + ExtensionShims 三层设计，跑通 Chrome 扩展生态
- 对比 Safari 1.2GB/10tab vs Chrome 2.1GB/10tab（M3 Mac），WebKit 阵营内存优势明显
- 坑：非公证 DMG 首次需右键打开、shim 补的 API 不保证 100% 兼容、无 App Store 分发
- 适合：想要 Safari 性能 + Chrome 扩展生态的 Mac 用户，尤其是 8GB 内存机型
6MB 是什么概念？——先看内存账本
先看一组 2026 年 1 月 BrowserBench 的实测数据（M3 Mac，16GB RAM，10 个混合标签页：YouTube/Reddit/Gmail/Twitter/Google Docs/NYTimes/GitHub/Stack Overflow/Notion/Figma）：
| 浏览器 | 内核 | 10 标签内存 | Speedometer 3 | 体积 |
|---|---|---|---|---|
| Safari 18 | WebKit | 1.2 GB | 45.2 | 系统自带 |
| Chrome 147 | Blink | 2.1 GB | 38.7 | ~300MB |
| Search | WebKit | 未公布（预期接近 Safari） | 未公布 | 6MB |
Chrome 比 Safari 多占 75% 内存，Speedometer 3 慢 17%。在 8GB MacBook 上（Apple 2024 年底还在卖），这个差距直接体现为卡顿。
Search 的 6MB 体积意味着它不包含任何内核代码——WebKit 是 macOS 系统组件，Search 只是一个"壳"。这个壳的体积只有 Chrome 的 1/50，但因为它跑的是同一个 WebKit，理论上性能应该看齐 Safari。
Chrome 扩展怎么跑在 WebKit 上？——三层补丁
这是 Search 最硬核的部分。WebKit 和 Chrome 的扩展 API 完全不同：Chrome 用 chrome.* 命名空间，WebKit 用 WKWebExtension。Search 的解法是三层：
第一层：WKWebExtension 桥接。 macOS 15.4+ 的 WebKit 提供了 WKWebExtension 框架，Search 的 Extensions.swift 实现了标签页、窗口、权限、弹窗的 WebKit 侧契约。这是地基。
第二层：CRX3 签名校验。 Crx.swift 从 Chrome Web Store 的公共更新地址拉取扩展，在解压前先用扩展 ID 校验 CRX3 签名。这一步防止了篡改扩展包——你装的是 Chrome Web Store 里那个扩展，不是被中间人改过的版本。
第三层：ExtensionShims 补 API。 这是真正的魔法。WebKit 缺 userScripts、privacy、browsingData、sessions、旧 FileSystem API 等 Chrome 扩展常用的 API。Search 在扩展安装时，往 worker、页面、content script 里注入一小段脚本，把这些缺失的 API 定义为"由 Search 原生回答"的调用。
打个比方：WebKit 是一栋毛坯房，Chrome 扩展是精装家具。Search 不换房子，而是给每个家具配了一个转接头——插上就能用，但偶尔会接触不良。
真实体验：能用什么，不能用什么
能用的：
- Chrome Web Store 扩展直接安装，签名校验通过后即可使用
- 每日自动更新，验证 Office Commun 签名后静默替换，下次启动生效
- 独立 cookie jar，关闭后不留痕迹（隐私浏览模式）
- 开发者可以加载未打包扩展文件夹，改完按 Reload，和 Chrome 开发者模式一样
不能用的 / 需要留意的：
- 非公证 DMG。Search 不在 App Store，也不是 Apple 公证的 DMG。首次打开需要右键 → 打开，之后正常。这是 macOS 对非 App Store 应用的通用限制，不是 Search 的 bug。
- shim 兼容性不保证 100%。ExtensionShims 补的是 API 调用，但 WebKit 和 Chrome 在行为上有差异：页面不回复的应答、worker 启动后添加的监听器、WebKit 丢失的 worker——这些边界情况 Search 在修，但不保证所有扩展都完美运行。
- macOS 15.4+。WKWebExtension 是 macOS 15.4 才有的 API，老系统用不了。
和现有 Mac 浏览器比，Search 的位置在哪？
| 浏览器 | 内核 | 扩展生态 | 体积 | 活跃度 | 适合谁 |
|---|---|---|---|---|---|
| Safari | WebKit | Safari 扩展（生态小） | 系统自带 | 苹果维护 | 追求极致续航和系统集成 |
| Chrome | Blink | Chrome 扩展（最全） | ~300MB | Google 维护 | 需要最全扩展 + Google 生态 |
| Arc | Blink | Chrome 扩展 | ~200MB | 已停止活跃开发 | 已停更，不建议新入 |
| Orion | WebKit | Chrome + Safari 双扩展 | ~100MB | 活跃 | 隐私优先 + 双扩展商店 |
| Search | WebKit | Chrome 扩展（shim） | 6MB | 活跃（开源） | 想要 Safari 性能 + Chrome 扩展 |
Arc 已经停止活跃开发（官方确认），不建议新用户入局。Orion 是 WebKit 阵营的老玩家，支持双扩展商店，但体积 100MB 且闭源。Search 的 6MB + 开源 + Chrome 扩展直装，在 WebKit 阵营里是独一份。
我的建议
8GB 内存 MacBook 用户：Search 值得试。WebKit 的内存优势在低配机器上是刚需，Chrome 扩展生态又补上了 Safari 最大的短板。
16GB+ 内存、Google 生态重度用户：Chrome 仍然是更省心的选择。Search 的 shim 层意味着某些扩展可能行为异常，Google Workspace 深度集成也是 Chrome 的独家优势。
隐私优先用户：Orion 仍然是更好的选择——双扩展商店 + 无追踪，Search 的独立 cookie jar 虽然好，但整体隐私设计不如 Orion 成熟。
常见问题
Q1: Search 是 Safari 的套壳吗？
A: 不是。Safari 是苹果的完整浏览器产品，Search 是调用系统 WebKit 内核的独立应用，有自己的扩展桥接层、自动更新机制和 UI。
Q2: Chrome 扩展能 100% 兼容吗？
A: 不能保证。ExtensionShims 补了 userScripts、privacy、browsingData 等 API，但 WebKit 和 Chrome 的行为差异（页面不应答、worker 丢失等）需要逐个修。大部分常用扩展应该没问题，但冷门扩展可能异常。
Q3: 为什么只有 6MB？
A: 因为 WebKit 是 macOS 系统内核，Search 不包含任何渲染引擎代码，只是一个原生壳 + 扩展桥接层。
Q4: 安全吗？非公证 DMG 是不是有风险？
A: 非公证 DMG 是 macOS 对非 App Store 应用的通用限制。Search 开源，代码可审计。扩展安装有 CRX3 签名校验，防止篡改。自动更新验证 Office Commun 签名。
Q5: 支持 iOS 吗？
A: 不支持。WKWebExtension 是 macOS 15.4+ 的 API，iOS 上所有浏览器都是 WebKit 壳，无法安装第三方扩展。
Q6: 和 Orion 怎么选？
A: Orion 支持 Chrome + Safari 双扩展商店，闭源，体积 ~100MB。Search 只支持 Chrome 扩展（通过 shim），开源，体积 6MB。要双扩展选 Orion，要极致体积和开源选 Search。
Q7: 会自动更新吗？
A: 会。每天检查一次更新，下载后验证 Office Commun 签名，静默替换，下次启动生效。