一周拿下749颗星，这个macOS小浏览器到底在解决什么问题
一个用Swift写的macOS小浏览器，7天749颗星。它不卷功能，只回答一个问题：你能不能用一个窗口，就把搜索这件事做完。
适合：想在macOS上拥有一个干净、轻量、专注的搜索入口，同时保持主力浏览器完整体验的用户。
先说结论
这不是一个来抢Chrome饭碗的项目。driceroland/Search给自己的定位很克制：一个用Swift写的、体积轻量的WebKit浏览器，跑在macOS上。它这一周拿到749颗星，并不是因为跑分高，而是因为很多人受够了“在浏览器里被绑架”。
真正的问题
普通用户用浏览器，嘴上说的是搜索，身体却在干三件事：在标签栏里拼关键词，在搜索结果里分辨广告，再点进一个被追踪器包围的页面。
Search的切入点很朴素：把搜索框单独拎出来，做成一个轻量入口，背后的渲染仍然交给WebKit。它不是要做下一个操作系统，而是在“搜索→阅读”这条最短路径上，把不必要的重量削掉。
对macOS用户来说，这恰好戳中了几个长期没解决的别扭：
- 系统自带的搜索入口分散在Spotlight、Safari和各类App里，规则不一致。
- 主流浏览器越做越重，启动一个干净的搜索窗口，都要等几百毫秒。
- 隐私设置藏在多层菜单里，多数人根本不会去调。
所以“星标”涨得快，不是因为炫技，是因为它回应了一个很日常的不爽。
怎么做更省力
如果你是macOS用户，又对Safari和Chrome的负担有点意见，可以按这个顺序试一下：
1。 先用一周观察自己每天打开浏览器的真实动作：到底是查资料多，还是被推送、邮件、收藏夹牵进去多。 2。 把Search当成“搜索专用窗口”，日常阅读和复杂页面继续留在主力浏览器里。 3。 在Search里设置好默认搜索引擎、关闭不必要的扩展加载，让冷启动保持在几百毫秒以内。 4。 如果你日常要处理图文排版、公众号文章这类内容，可以用公众号AI排版编辑器把查到的资料快速整理成可发的稿子，省去复制粘贴到Word再调格式的步骤。
这套打法的关键，是不跟自己的习惯硬刚。一个工具负责干净搜索，另一个工具负责把搜索结果变成可发布的成品，比硬塞进一个“超级App”要省心得多。
| 场景 | 主力浏览器 | Search + 排版工具 |
|---|---|---|
| 查资料 | 顺手 | 更专注，少干扰 |
| 阅读长文 | 体验完整 | 窗口小，沉浸 |
| 输出公众号 | 需要手动整理 | 一键成文 |
| 隐私要求 | 看设置 | 默认更克制 |
哪些坑要避开
第一，别把它当主力浏览器来用。它目前的定位是入口级，不是Chrome替代品，扩展生态和复杂站点兼容性还不是它要解决的问题。
第二，别在Seed期就急着All in。749颗星说明关注度高，但不代表功能已经稳定，Swift项目的早期版本在内存管理和WebKit兼容性上很容易踩坑，先小范围试用，别把工作流全压在它上面。
第三，别忽略macOS本身的权限设置。沙盒、辅助功能、网络代理这些开关没配好，再轻的浏览器也会出现加载慢、字体异常、跨域失败这些老毛病。
第四，不要为了“轻”而牺牲掉基本的阅读体验。字体渲染、夜间模式、阅读模式这些细节没调好，长文阅读反而会更累。
现在就能动手
打开终端，把仓库克隆下来：
git clone https://github.com/driceroland/Search然后用Xcode打开，按照官方说明配置签名和Sandbox权限，先跑一个最小搜索窗口。把它固定在Dock里当成“第二浏览器”，平时只用来做“查”和“读”，不指望它管“写”和“发”。如果你还要把搜索结果变成可发的内容，再用排版工具接力。
一周时间，足够判断它值不值得长期留在你的菜单栏里。