fox_charon：自托管个人起始页，把“收藏”变成“重逢”

凌晨两点，我看着自己浏览器里第47个关于“待读”、“稍后整理”、“灵感碎片”的书签目录，终于承认了一件事：我囤积的不是知识，是数字垃圾。那些收藏的网页，再也没有打开过第二次；那些截图保存的文章，永远沉睡在相册深处。我需要的不是更强大的收藏工具，而是一个能把“收藏”变成“重逢”的地方。于是就有了 fox_charon。

fox_charon 是一个自托管的个人浏览器起始页，也是一个轻量级“数字摆渡人”。它帮你把散落在各个收藏夹、书签栏、笔记软件里的链接，统一收容到一个带搜索、标签、稍后读、暗色模式的本地面板里。数据全部留存在浏览器本地，不需要服务器，不需要账号，打开即用，也可以部署到任意静态托管平台。这个项目最核心的设计理念只有一个：让每一个被存档的页面，都有被再次打开的理由。

如果你正在被收藏夹爆炸、书签有去无回、想搭个人导航页却不知道从何下手这些问题困扰，这篇博文会把 fox_charon 从取名思路、技术选型，到踩坑排障，完整拆开给你看。

1. fox_charon 从哪来：一个重度书签囤积者的自救

先聊聊这个名字。fox 是灵巧、敏感、好奇心重的动物，charon 是神话里负责把灵魂渡过冥河的摆渡人。组合在一起，我的定位就清晰了：一只狐狸，驾着一艘小船，在每天的信息洪流里来回摆渡，把值得的东西从“当前焦虑”运到“长期记忆”的对岸。

这个项目诞生的直接诱因非常不体面：我发现自己收藏了大量内容，但这些东西不仅没有形成知识体系，反而让我的信息焦虑越来越严重。每次打开浏览器，看到那一排排的书签，我心里很清楚——这里面95%我永远不会再点开，但我害怕删掉它们，万一下次要用呢？这种“收藏等于拥有”的错觉，是数字囤积症的核心症状。

我去市面上找过工具。浏览器自带的收藏夹功能太弱，标签和全文检索都是奢侈品；一些在线书签服务是够强，但它们把数据存在别人服务器上，难保哪一天服务就停止了；浏览器扩展确实生态好，可我对第三方插件的权限天然不信任。说白了，我要的是：本地优先、开源透明、切换浏览器和换设备都不受制于人。

fox_charon 的架构很直白，整个项目是纯前端 SPA，没有后端。数据层用 IndexedDB 存储，用 localStorage 做快速读写缓存，通过 file:// 协议或者任意 HTTP 静态服务器都能跑。主力开发形态是一个类似 Chrome 新标签页的起始页，但比它多了一套完整的“存、取、搜、读”闭环。

为什么要本地优先？因为我在意两件事：可用性和持久性。本地优先意味着哪怕全世界网络断了，我的收藏依然在硬盘上；数据格式我用 JSON 导出功能做了兜底，理论上任何浏览器，只要支持 IndexedDB，我就能把数据平滑迁过去。网络收藏服务固然方便，但属于“把命脉交给平台”，这不是我想要的。

2. 渡口设计：先把“收藏之后”这条链路想清楚

动工之前我逼自己回答一个问题：一个链接从“看到”到“真正读完”，中间要经过哪些环节？我梳理出来的链路是这样的：发现信息 → 快速留存 → 分类归置 → 再次访问 → 深度阅读 → 沉淀/清理。绝大多数收藏工具只做了前两步，fox_charon 想覆盖的是中间四步。

基于这个链路，我给 fox_charon 定了五个核心功能模块：

功能之外还有一个贯穿全局的设计原则：不给用户增加管理负担。很多人做导航页容易犯一个错误，把分类逻辑定得太重，什么“工作/学习/生活”一级目录下面再套二级三级。这对新收藏的录入是灾难性的——你得先想清楚这一篇属于什么目录，然后就懒得存了。

fox_charon 的默认交互完全围绕“轻量”两个字设计：新增一条收藏，默认塞进“收件箱”，标签可填可不填。每周日我会花五分钟整理收件箱，把还值得读的挂上标签，把已经没价值的删掉。这个“收件箱—归档—删除”的轻流程，是我用了一年多之后真正觉得舒服的节奏。

技术上，整体数据模型只有一种对象，叫“item”，包含这些字段：

json复制{
  "id": "uuid_v4_generated_by_client",
  "url": "https://example.com/long-read",
  "title": "某篇深度报道标题",
  "tags": ["深度阅读", "行业观察"],
  "status": "inbox | pending | archived | dropped",
  "createdAt": "2024-06-01T10:30:00.000Z",
  "lastOpenedAt": null,
  "readCount": 0,
  "notes": ""
}

也许有人会问：status 里为何还要留一个 dropped？我的解释是，删除操作也是需要犹豫成本的。与其一开始就想“要不要删”，不如把“暂时不要了”做成一个显式状态，让数据先淡出视野。这一点是从 GTD 方法里的 trash 概念借来的思路，实际体验下来，它能有效降低整理的决策疲劳。

3. 关键实现：收藏夹废墟是怎么被一段段代码清理干净的

功能白板画完之后，我开始动手写第一版。开发过程中踩到的几个关键细节，我觉得比功能本身更值得记录。

3.1 剪贴板智能识别，把“添加”浓缩到一次按键

fox_charon 里使用频率最高的操作是新增收藏。为了把操作成本压到最低，我做了一个“粘贴即解析”功能：页面里只有一个输入框，用户的剪贴板里如果是 URL，应用会主动去尝试抓取链接的标题和描述；如果剪贴板里是纯文本，那就当作备注处理。

原理很简单，监听 paste 事件，读取剪贴板内容，用正则判断是否 http/https 开头。如果是链接，为了防止跨域拿不到 title 标签，我走的是后端代理接口，让服务端去请求目标页面并解析 <title>。注意，这里我特意说了后端，因为纯前端的 fetch 直接抓目标页面，十有八九会被 CORS 策略拦下来。

代理接口核心逻辑大概长这样：

python复制from flask import Flask, request, jsonify
import requests
from bs4 import BeautifulSoup

app = Flask(__name__)

@app.route("/fetch-title")
def fetch_title():
    url = request.args.get("url", "")
    if not url.startswith(("http://", "https://")):
        return jsonify({"error": "invalid url"}), 400
    try:
        resp = requests.get(url, timeout=10, headers={
            "User-Agent": "Mozilla/5.0 (compatible; fox_charon/1.0; +https://github.com/yourname/fox_charon)"
        })
        soup = BeautifulSoup(resp.text, "html.parser")
        title = soup.title.string.strip() if soup.title else url
        return jsonify({"title": title})
    except Exception as e:
        return jsonify({"title": url, "error": str(e)})

这里有个细节要注意：requests 请求的头里必须带一个正常的 User-Agent，否则很多站点会把你当爬虫直接拒绝。另外 timeout 一定要给，不然碰到响应极慢的网站，你的保存动作会卡到天荒地老。

我自己部署的时候把这个代理服务跑在一台 1 核的小机器上，实际上每天请求量非常少，几十条的规模，它毫无压力。这也侧面说明，一个看起来“需要服务端”的能力，用最廉价的方案就能解决，纯粹为了这个功能去引入重后端框架是没必要的。

3.2 静态快照与“假快照”背后的妥协

“网页会消失”，这是收藏工具的永恒痛点。今天收藏的文章，可能三个月后链接就 404 了。很多稍后读工具提供“永久存档”功能，方案基本都是后台把网页正文抓下来存进自己的服务器。这个做法我当然知道，但我不愿意为了个人使用去维护一个网页抓取集群。

fox_charon 的妥协方案是“非完美快照”：可以选择把网页正文通过 Readability 算法（mozilla 开源的正文抽取库）解析后，保存成纯文本或 Markdown 实体存储进 IndexedDB。这样即便原链接失效，你依然能看到正文内容，只是丢失了排版和图片之类的东西。

用 Readability 抽取正文的代码长这样：

javascript复制import { Readability } from '@mozilla/readability';
import { JSDOM } from 'jsdom';

export async function snapshotContent(url) {
  const response = await fetch(`https://your-proxy.example.com/fetch-page?url=${encodeURIComponent(url)}`);
  const html = await response.text();
  const dom = new JSDOM(html, { url });
  const article = new Readability(dom.window.document).parse();
  return article ? article.textContent : null;
}

注意这里的坑：Readability 依赖 DOM 节点里的大量结构信息，如果直接把有响应式的现代网站喂进去，它经常抽取出一些导航、推荐模块的残留文字。所以我在接入时还做了一层额外的清洗：过滤掉 article 里所有包含 nav、footer、aside 类的节点再喂给 Readability。实测下来干净程度能提升不少。

另外一个必须接受的事实是：存正文会占用空间。一篇普通文章转成纯文本大概是几十 KB 的量级，一万篇文章才几个 GB。IndexedDB 的配额在 Chrome 下通常按磁盘剩余空间计算，个人使用完全够。但如果你收藏的内容里有很多图片型页面，纯文本就不够用了，那需要另行设计方案，后文我会聊到。

3.3 全文索引的轻量实现：不用 Elasticsearch 也能搜得动

搜索是 fox_charon 的门面功能。一开始我天真地想：直接用 IndexedDB 的游标遍历，然后用字符串 indexOf 做子串匹配不就行了？结果数据量到几千条以后，肉眼可见地卡顿。每次搜索要扫一遍全部记录，哪怕 IndexedDB 是异步的，浏览器主线程也会因为频繁的字符串匹配而掉帧。

后来我把方案升级成了倒排索引。做法很朴素：每保存一个条目时，把标题、正文、标签文本切成词汇数组，然后建立一个 { keyword: [itemId, itemId] } 的映射表。查询时先查映射表拿到候选条目 ID 集合，再回主表取详情。因为 ID 是唯一的，集合运算可以在内存里做交集和并集，速度非常快。

javascript复制class InvertedIndex {
  constructor() {
    this.map = new Map(); // keyword -> Set<itemId>
  }

  addItem(item) {
    const tokens = this.tokenize(`${item.title} ${item.tags.join(' ')}`);
    for (const token of tokens) {
      if (!this.map.has(token)) this.map.set(token, new Set());
      this.map.get(token).add(item.id);
    }
  }

  search(query) {
    const tokens = this.tokenize(query);
    if (tokens.length === 0) return [];
    let resultSet = null;
    for (const token of tokens) {
      const set = this.map.get(token);
      if (!set) return [];
      if (resultSet === null) {
        resultSet = new Set(set);
      } else {
        resultSet = new Set([...resultSet].filter(id => set.has(id)));
      }
    }
    return [...resultSet];
  }

  tokenize(text) {
    return text.toLowerCase()
      .replace(/[^\w\u4e00-\u9fa5]+/g, ' ')
      .split(' ')
      .filter(token => token.length > 1);
  }
}

中英文混合分词是最容易出问题的地方。中文不像英文有天然空格，所以上面的 tokenize 里我直接保留连续的汉字串作为一个整词处理。这样的索引精度不高，比如你搜“网络”搜不到“互联网”里的“网络”，但对个人收藏的数据量来说，这个精度损失完全可接受。如果真要做到更细的中文分词，可以引入一个轻量的分词库在本地跑，但我个人认为维护成本大于收益，不推荐。

为什么不做模糊匹配的前缀建议？比如输入“fox”匹配到“fox_charon”？这个能力在搜索框下拉框里确实是加分项，但它的本质是额外的索引 + 内存常驻。为了一个非核心体验，我不愿意增加复杂度。fox_charon 的策略是“搜得准优先于搜得快”，反正数据在本地，几万条以内的数据量，不管怎么搜都是毫秒级，没必要为了最后那 200 毫秒的提前量去优化。

4. 渡河时翻过的船：实测中遇到的三处硬伤与排障记录

功能做出来之后，我当然以为自己已经大功告成，但实际用在日常浏览器里的第一周就翻了三次船。这三处的根因各异，很典型，值得单独铺开说。

4.1 网页截图“白屏”的真相：CORS 不是唯一的拦路虎

我很想让收藏卡片在起始页里显示一个缩略图。一开始是通过 canvas 把页面画出来，然后调用 canvas.toDataURL() 生成截图。逻辑上顺理成章对不对？实际跑起来，几乎有一半的网站截出来是白屏或黑屏。

排查链路如下：

第一反应是 CORS。如果页面里加载了跨域图片资源，canvas 会被污染，toDataURL 会直接抛安全错误。于是我先把所有图片请求都改成了走代理，重新截图，发现问题依旧。

第二次怀疑是某些站点开启了反自动化检测，返回的 HTML 里 JS 检测到无头浏览器就拒绝渲染。可我用的不是无头浏览器，就是普通的 iframe 嵌入。也排除了。

第三次排查，我在浏览器开发者工具里手动加载了那些“白屏”站点，发现它们的页面能正常渲染，但有一个共同特征：页面上使用了 CSS mix-blend-mode 或者全屏动画。更致命的是，它们的背景色是透明的，本身没有给 body 或者根容器设置底色。截图时 canvas 画布默认透明，合成后就变成了白色或黑色。

解决方案本质上不复杂，做一个“先铺底色再加载页面”的容器即可。如果是抓取截图，则在无头浏览器里先执行一句 document.body.style.backgroundColor = '#fff'。我的 fox_charon 没有选择在本地做截图，而是把这个需求外包给了自建的截图服务，它内部使用无头浏览器，设置窗口大小 1280x720，加载完成后等待 3 秒再截，实际效果稳定很多。

如果你也想自己接一个截图服务，请务必要注意：一定要设置较长的超时和失败重试，否则那些包含大量外部视频、广告脚本的网站会把你的截图进程拖垮。常见做法是单页最长 15 秒强制截断。

4.2 localStorage 的“隐性地雷”：和 IndexedDB 混用时的容量坑

数据存储我一开始规划得很“双轨”：条目元数据放在 localStorage，方便同步读；全文正文和索引放在 IndexedDB。因为 localStorage 是同步 API，取标题列表时不需要走异步，界面能秒开。

这个设计在数据量约 2000 条以前是正常的。从某一天起，网页控制台开始零零散散报错，提醒 localStorage 容量不足。我第一反应是：不可能啊，一条元数据撑死 500 字节，5000 条也才 2.5MB，localStorage 的标准限额是 5MB 左右。

后来我做了个测试，遍历所有 key，统计各 key 的 value 长度，发现罪魁祸首是“文章快照的纯文本自动备份”功能。我当时图省事，每次抓取正文后会把 Markdown 原始文本的摘要（前 2000 字）顺手写进了 localStorage。一篇两三千字，写了几百篇之后，5MB 被你塞满了。

这里必须提醒所有用 localStorage 的人：它本质上是个同步阻塞的 key-value 仓库，不是给大对象当缓存用的。凡是可能超过几十 KB 的内容，一概丢给 IndexedDB。

修复过程很简单，我把 localStorage 里的正文摘要字段全部清掉，只保留 id、url、title、tags、status 这些短字段，正文一律从 IndexedDB 读取。针对已经写入脏数据的用户，写了个一次性迁移函数：

javascript复制async function migrateLocalStorageToIndexedDB() {
  const keys = Object.keys(localStorage);
  for (const key of keys) {
    if (key.startsWith('fox_charon_snapshot_')) {
      const itemId = key.replace('fox_charon_snapshot_', '');
      const content = localStorage.getItem(key);
      await saveSnapshotToIndexedDB(itemId, content);
      localStorage.removeItem(key);
    }
  }
}

迁移后在应用启动时自动检测版本号，一劳永逸。

这套“短字段走 localStorage、长字段走 IndexedDB”的双层架构，之后稳定跑了很久没再出问题。给一个参考标准：凡是你预估单条数据小于 5KB 的，可以放 localStorage；单条大于 100KB 的，想都别想，必须 IndexedDB；中间态按实际读写频次决策，不要迷信某一层。

4.3 应用内打开网页的“鸡生蛋”困局：X-Frame-Options 与最朴素的重定向

fox_charon 有一个“在应用内直接阅读”的交互，点开卡片就能在当前页面显示目标网页的 iframe。这个体验对标的是各大稍后读工具的内置浏览器。结果我发现，大概有 30% 的网站根本不愿意被 iframe 嵌套，因为它们设置了 X-Frame-Options: DENY 或者 SAMEORIGIN 响应头。

这个问题在开源社区里是无解的——除非你做一个远程浏览器，通过后端渲染把网页内容“洗”一遍再传回来，但这会引出更大的安全和成本问题。于是我在产品层面做了取舍：

• 默认行为改为“点击卡片，新标签页打开原链接”，保证无论如何都能访问。
• 对明确允许被 iframe 嵌套的网站（例如部分博客、文档站），我用一个“尝试预览”按钮做二次确认。
• 数据上记录了每个网站的历史打开成功率，遇到连续失败的域名，自动移出“可预览列表”。

这种降级策略很重要，也是很多开发者容易忽略的：功能不可用时，不要让用户撞上一堵抽象的安全墙，而是主动给他一条更绕的路。

另外我在日志里偶然发现一个现象：部分用户点预览失败后会狂点，以为是自己网络问题。后来我在错误提示里加了按钮“打开原链接”，这个按钮的点击率极高，说明很多人需要的其实只是“别拦着我出去”。

5. 如果只留一句话：把工具的低摩擦放在第一位

有人可能期待我写一份“如何从零搭一个 fox_charon”的详细教程，但其实我把核心代码整理好之后，部署它只需要三步：把前端静态文件扔到任意静态托管；写一个 50 行的抓标题代理；浏览器设置里把新标签页指向它的地址。

真正值得耗费心思的地方不在于实现，而在于反复确认三个问题：

第一，用户保存一条收藏需要几步？超过三步就是失败。fox_charon 的最短路径是聚焦输入框 → 粘贴 → 回车，三步以内完成。这在产品术语里叫“采集摩擦”，它是整个工具的生命线，摩擦稍高你就会回到“先放收藏夹以后再说”的旧习惯里。

第二，收藏之后多久能“再见”？我观察到一个规律，凡是一周内没有被再次打开过的收藏，它在一个月后被打开的概率呈指数下降。fox_charon 的“渡口”随机重访按钮，就是针对这个下降曲线做的干预。它每次只给你看一条旧收藏，但配合 30 秒的阅读倒计时，确实能逼着我把一些干货内容真正看了。

第三，万一服务挂了，我的数据还能回来吗？这句话听起来老生常谈，但对本地优先应用来说是铁律。项目里我加了一个“导出完整数据为单个 JSON 文件”的按钮，每周导出一次，存到网盘备份。JSON 格式是一种既笨又可靠的存在，只要文件还在，任何环境下都能重新导入。

开发过程中我还发现了一个违背直觉的现象：把功能做得极简之后，用户反而会更依赖它。早期版本我加入了“标签自动联想”“相似文章推荐”“月度阅读报告”等功能，结果这些炫酷功能的使用率几乎为零，反而因为增加理解成本让人望而却步。后来我把它们全砍了，只保留“存、搜、开”三个动作，收藏量从每周个位数涨到了每天六七个。

这让我想起一个比喻：工具不是仓库管理员，而是渡口的一个船夫。你不能要求每个过河的人先学会游泳、再登记身份证、再选座位号——你要做的只是稳稳地把船撑到对岸。这一点，大概也是 fox_charon 这个名字带给我最大的启示。