打开自己的聊天记录搜索栏输入一个关键词翻了十几页,那种又熟悉又陌生的挫败感,大概每个长期在网络上做资料收集的人都经历过。你明明记得三个月前看过一篇非常对症的文章,记得它的配图长什么样,甚至记得当时在哪个上下文里遇到它,唯独找不到那条链接。收藏夹里倒是塞了几百条,可真要找的时候,要么忘了当初给它起了什么名字,要么压根没起名字,只剩一串光秃秃的地址。这也是我后来动手折腾Furl这类 URL 管理工具的根本原因——不是缺一个存链接的地方,而是缺一套能把链接整理干净、检索得到、活得够久的机制。这篇内容会从 URL 清洗、标签体系、检索实现、巡检机制、数据落地形态这几个角度,把一个简洁的 URL 管理工具到底是怎么被设计出来的拆开讲清楚。它适合那些想自己写一个本地工具、或者想把现有收藏夹彻底重构一遍的读者,哪怕你只是用过书签而没写过一行代码,也能从里面找到可以直接照搬的规则和参数。1. 为什么存链接这件小事值得单独做一套工具1.1 链接失序的真实成本,比想象中高得多大多数人管理链接的方式,本质上只有三种:浏览器书签、聊天软件里的发给自己、以及临时记在某个笔记文档里。这三种方式有一个共同的缺陷——入库的成本极低,出库的成本极高。往书签里加一条链接只需要一次点击,但当你有八百条书签的时候,想从里面捞出特定的三条,你付出的检索成本已经远远超过了当初省下的那一次点击。我在做这套东西之前,专门统计过自己的收藏行为:平均每天会新增 6 到 10 条想留存的链接,一个月下来两三百条,三个月就是一个没人敢打开的抽屉。这些链接里,真正会被再次访问的可能只有 15% 左右,但问题在于你事前没法判断哪 15% 有用,所以只能全存,于是全都被淹没。更麻烦的是重复——同一条内容从不同渠道进来,带着完全不同的跟踪参数,系统认为它们是两条,你也被迫在两条之间犹豫。所以一个 URL 管理工具真正要解决的不是存储,而是三个更靠后的问题:入库时把噪音除掉,存储时把结构建好,出库时把入口做短。Furl 这个名字听起来轻,但它的重心其实全在这三件事上,界面反而是最不值钱的部分。1.2 Furl 的定位边界:它明确不做什么把边界说清楚,比把功能罗列一遍有用得多。我在设计 Furl 的时候给自己划了几条硬线,后面所有的技术选择都是这几条线推导出来的:不做云端账号体系。一旦有账号,就有同步冲突、就有数据归属、就有服务停了你的链接怎么办的问题。所有数据落在本地一个文件里,复制走就是完整迁移。不做社交化发现。不做推荐、不做公开主页、不做热门列表。这类功能会立刻把工具从我的资料库变成另一个信息流,而信息流恰恰是问题的源头。不做全自动整理。自动打标签、自动归类听起来很香,但准确率一旦卡在 70% 左右,你就得花更多时间去纠正它,比自己手工打还累。宁可让用户手打两个标签,也不要给一堆似是而非的建议。不追求跨端全覆盖。优先把桌面端的命令行和一份稳定的数据格式做扎实,移动端靠导出和只读浏览解决,而不是每端都做一套半成品。这几条边界带来的直接好处是:整个工具的核心可以压缩到一层 URL 处理逻辑 一个本地数据库 一组命令或快捷键。没有网络依赖的部分占了九成,调试起来极其轻松,也不存在服务不可用这种故障模式。1.3 本地优先这个决定,改变了后面所有的架构很多人会觉得数据存本地只是隐私考虑,其实它对工程结构的影响要大得多。因为数据在本机,你可以肆无忌惮地建索引、跑全文检索、做批量重写,不用担心流量和配额;因为数据在本机,抓取标题、巡检死链这种重操作可以放到后台慢慢跑,失败了大不了重来;也因为数据在本机,备份的责任回到了你自己身上,这一点必须有清醒认知。我个人的做法是三层备份:第一层是数据库文件本身定时快照,第二层是每周导出一次纯文本清单(URL 标题 标签,一行一条),第三层是把这份纯文本同步到另一个物理位置。第三层尤其重要——纯文本清单的意义在于,即使哪天工具本身跑不起来了,你手里仍然有一份人眼可读、任何编辑器都能打开的链接资产,不至于被某个软件的私有格式锁死。这个思路我在后面第 5 章还会展开讲,因为它决定了表结构怎么设计才不至于把自己坑住。2. 链接入库前的清洗关:把 URL 当数据看,而不是当字符串2.1 那些看着有用、其实全是噪音的查询参数从任何渠道复制来的链接,大概率都不是干净的。社交平台、内容平台、搜索引擎、邮件客户端,几乎都会往 URL 后面挂一串跟踪参数。它们的共同特征是:对内容定位毫无作用,但会让同一条内容在数据库里变成好几条不同的记录,并且让链接长到在终端里换行。常见的那几类,我整理成一张表,方便你直接对照自己的数据看:参数类别典型参数名处理建议投放跟踪utm_source、utm_medium、utm_campaign、utm_term、utm_content、utm_id一律丢弃,这类纯属归因用平台渠道spm、scm、share_source、share_medium、share_plat一律丢弃,多见于内容平台分享链接广告点击gclid、fbclid、msclkid、yclid、dclid一律丢弃邮件营销mtm_campaign、mtm_source、hsa_*、pk_*一律丢弃语义模糊ref、from、source、src、via不能硬编码丢弃,部分站点的source是真实内容参数最后一行是大坑。我一开始图省事,把ref、from、source全都塞进了丢弃列表,结果某个站点的图片地址是...?sourcexxx,一清洗全变成 404。后来改成默认保留,命中时才提醒,才把误伤率降下来。这个教训很朴素:凡是语义可能是业务参数的字段,都不该进硬编码黑名单,只能进可配置的软名单。2.2 规范化规则表:大小写、末尾斜杠、锚点、默认端口清洗完查询参数,接下来要处理 URL 的结构部分。这里的依据是 URI 的通用规范,但落地上有一些需要你自己拍板的细节。我实际采用的是这套规则:组成处理规则理由scheme强制小写,仅允许http/https大小写混写在比较时会漏判host强制小写,去掉末尾的点域名本身不区分大小写porthttp:80和https:443的显式端口去掉否则:443和空端口会被判成两条path保留原样,不改大小写;空路径补为/路径在很多服务端是大小写敏感的,改了就 404query参数按键名排序,保留重复键的相对顺序排序后才能稳定判重fragment默认去掉锚点通常不影响内容本身关于 fragment,有一个必须例外的情况:前端路由的页面,内容其实完全由锚点决定,比如#/article/123这种。我的判断逻辑是——如果 path 为空或仅为/,且 fragment 以!或/开头,就保留 fragment;其余情况一律丢弃。这一条规则挡住过我好几次看起来重复但其实是不同页面的误合并。还有两个容易忽略的点。其一是 IPv6 地址:正规写法要求方括号包裹,如果你在拼接 netloc 的时候只取 hostname 会丢掉方括号,导致拼出::1:8080这种非法串。其二是百分号编码:空格到底编成%20还是,不同实现不一样,统一按%20处理、且不重复编码已经编码过的序列,这一条要靠实际数据反复试。2.3 去重到底该按原始串、规范化串还是内容指纹这是整个清洗流程里最需要想清楚的一个决策。三种做法各有代价:按原始串去重,优点是绝对安全、绝不误合并,缺点是几乎没什么用,因为同一条链接的十几个变体会全部留下来。按规范化串去重,是我最终选的方案,平衡点最好——它能吃掉端口、大小写、参数顺序、跟踪参数这些确定性的差异,同时不会改变指向内容本身。按内容指纹去重(先抓页面再算正文哈希),理论上最准,但成本极高:每条链接都要实际请求一次,遇到登录墙、反爬、动态渲染就全都失效,而且删除时机的判断会变得非常复杂。规范化串去重还有一个隐藏好处:它天然给出了一个稳定的主键。我对规范化后的 URL 做一次 SHA-256,截取前 16 个字节的十六进制作为url_key,存进数据库时加唯一约束。这样即使以后更换语言、更换实现,甚至把数据导到另一个工具里去,这个键仍然是确定可复现的,不会出现重新导入一遍全变成重复项的惨剧。2.4 一段可以直接抄走的清洗实现下面的实现是我实际在用的核心逻辑,依赖 Python 标准库,没有第三方依赖,可以直接改改就用:import hashlib from urllib.parse import urlsplit, urlunsplit, parse_qsl, urlencode DROP_PREFIXES (utm_, mtm_, hsa_, pk_) DROP_EXACT { fbclid, gclid, dclid, msclkid, yclid, spm, scm, share_source, share_medium, share_plat, } # 语义模糊的参数不删,仅做记录,留给用户判断 SOFT_HINTS {ref, from, source, src, via} def is_dropped(key: str) - bool: k key.lower() if k in DROP_EXACT: return True return any(k.startswith(p) for p in DROP_PREFIXES) def normalize(raw: str, keep_fragment: bool False) - str: raw raw.strip() parts urlsplit(raw) scheme parts.scheme.lower() if scheme not in (http, https): raise ValueError(funsupported scheme: {scheme}) host (parts.hostname or ).lower().rstrip(.) port parts.port if (scheme, port) in ((http, 80), (https, 443)): port None netloc host if port is None else f{host}:{port} path parts.path or / pairs [(k, v) for k, v in parse_qsl(parts.query, keep_blank_valuesTrue) if not is_dropped(k)] pairs.sort(keylambda kv: kv[0]) # 稳定排序,同键保持原序 query urlencode(pairs, doseqTrue) frag if keep_fragment and (path in (, /)) and parts.fragment.startswith((!, /)): frag parts.fragment return urlunsplit((scheme, netloc, path, query, frag)) def url_key(normalized: str) - str: return hashlib.sha256(normalized.encode(utf-8)).hexdigest()[:16]用法上,入库前先normalize,再算url_key,把url_raw(原始输入)、url_norm(规范化结果)、url_key(去重键)三个字段一起存下来。多存一份原始串的价值在于:万一某条规则把关重要的参数删错了,你还能回溯;而且原始串里往往带着来源信息,后期做渠道分析时用得上。注意:pairs.sort()用的是只按键名排序,这对绝大多数站点没问题,但如果某个接口把参数顺序当语义(罕见但存在),排序会改变行为。我遇到过的一次是某个文件下载接口依赖参数顺序签名,解决办法是对特定域名关闭排序,用一张域名例外表兜底。3. 标签与检索:让三个月后的自己还能把链接找回来3.1 我不推荐无限层级文件夹的三个理由收藏夹天然会演化成文件夹树,而文件夹树有一个几乎无法避免的结局——层级不断加深,分类边界不断模糊。我自己就建过技术/前端/构建工具/打包这种四级路径,建的时候觉得清晰,半年后完全想不起来某个东西当时放在构建工具还是打包下面。第一个理由是专属排他性。一条链接只能属于一个文件夹,但这篇文章可能同时是构建工具和性能优化和值得重读,文件夹逼你选一个,选错就再也找不到。第二个理由是维护成本随深度指数上升。目录一多,你就得不断地搬东西、合并目录、重命名,这些维护工作本身没有任何产出。第三个理由是检索能力被浪费。现代数据库的检索能力早就够用了,你却把分类的工作交给人工目录,等于用最贵的方式做最简单的事。标签体系不一样,一条链接可以挂多个标签,标签之间是并集关系,天然适合我记不清放哪了但我记得它跟什么有关这种真实场景。代价是标签会膨胀,所以需要一个约束机制。3.2 标签命名的一套土办法:前置维度 短词我用了两年多,效果最好的一套规则是维度前缀 短词的双段式命名:类型维度:type:article、type:tool、type:repo、type:video、type:doc状态维度:st:todo、st:done、st:archive、st:broken主题维度:自由短词,如db、css、cli、deploy,一律小写、不超过 12 个字符来源维度:src:newsletter、src:chat、src:search,用来回溯渠道前缀的好处是输入时能靠补全快速筛选——敲st:就只出状态类标签,敲ty就只出类型类,不会在几十个标签里迷路。短词的好处是抑制描述性标签的冲动,db比database-indexing-best-practice有用得多,后者其实是笔记该干的事,放note字段里更合适。还有一条铁律:标签总数控制在 60 个以内。超过这个数,补全列表就开始失去导航价值,你会开始退化成靠记忆输入。我每季度会跑一次标签统计,把出现次数小于 3 的标签挑出来合并或删掉,这个过程大概花十分钟,但能让整个体系保持可用。3.3 三种检索入口,对应三种不同的记忆状态人的记忆状态其实分三种,对应的检索策略完全不同,这也是我把查询入口设计成三套的原因:第一种,你记得开头。这时候前缀匹配最快。用户敲docs.就只出这个域名下的所有记录,敲htt就只出 URL 里以这个开头的。前缀查询一定要做成实时过滤,延迟控制在 50 毫秒以内,否则手感就废了。第二种,你记得某个词但不记得在哪。这时候需要全文检索,而且要同时覆盖标题、URL、备注三个字段。很多人只索引标题,结果链接标题是首页、文档中心这种毫无信息量的词,照样搜不到。把 URL 也纳入索引能救回很多这类情况,因为域名和路径里的词往往比标题更有辨识度。第三种,你记得的条件是组合的。比如去年存的那批关于数据库的文章里还没读的。这时候需要的是条件表达式,而不是关键词。我在 Furl 里做了一个极简的查询语法:tag:db tag:st:todo before:2024-06-01,多个条件之间默认是与关系。实现上不需要写解析器框架,一个正则把字段:值抽取成结构化条件即可,剩下的交给 SQL 拼接。3.4 本地全文检索的落地细节与几个实打实的坑如果选 SQLite 做存储,全文检索直接用 FTS5 就够了。难点不在能不能跑,而在分词。默认的unicode61分词器对中文几乎不可用,它会把一整段连续的中文字符当成一个词,导致你搜任何一个片段都命中不了。解决方案有三个,我按推荐顺序排:trigram分词器(SQLite 3.34 及以上)。把文本切成三元组,对中英文混排效果都不错,而且支持LIKE风格的模糊查询。代价是索引体积会涨到原文本的 3 到 4 倍,查询的字符串长度至少要 3 个字符才有意义。入库前手动切字。把中文按双字切分,用空格连起来,再喂给unicode61。实现简单,但对词语边界的处理比较粗暴。引入外部分词组件。效果最好,但要带一个不小的依赖,和简洁的定位有冲突。我最终用的是 trigram,建表语句大致如下:CREATE TABLE link ( id INTEGER PRIMARY KEY, url_key TEXT NOT NULL UNIQUE, url_raw TEXT NOT NULL, url_norm TEXT NOT NULL, title TEXT, note TEXT, created_at INTEGER NOT NULL, status INTEGER DEFAULT 0, -- 0 未检 1 正常 2 跳转 3 异常 4 消失 checked_at INTEGER ); CREATE VIRTUAL TABLE link_fts USING fts5( title, url_norm, note );这里我用的是独立内容表而不是外部内容表(contentlink),原因是外部内容表的同步要靠触发器维护,一旦有批量更新(比如全量重写规范化 URL)很容易出现索引和主表不一致,而且很难察觉。独立表的代价是多占一份存储、写入时要手动双写,但换来的是所见即所索引的确定性,对个人工具来说这笔账划算。还有一个非常容易踩的坑:trigram 索引下的短语查询。MATCH 数据库 索引这种带引号的短语写法在 trigram 下行为和unicode61完全不同,如果你的查询词是用户随手敲的,记得先做一次转义,把可能被当成 FTS 语法的字符(、*、^、:、(、)、-)处理掉,否则用户搜一个带减号的词就会直接抛语法错误。我在早期版本里因为这个报错崩过好几次。4. 抓标题与死链巡检:并发、限速与误判处理4.1 为什么非抓标题不可,以及抓不到时的兜底策略一条光秃秃的 URL,三个月后你几乎不可能认出它是什么。而一个像样的标题,能让整个列表瞬间变得可扫视。所以入库后异步抓取标题是这类工具的标配功能,但它的失败率比大多数人预想的高得多。我统计过自己那批链接的抓取结果,大致分布是这样的:能成功拿到title的约占 72%,需要跟随重定向才能拿到的占 11%,返回 403/401 的占 6%,超时的占 4%,其余是各种奇怪情况(返回空页、返回 PDF、返回 JS 渲染的空壳)。也就是说接近三成的情况下你抓不到标题,必须准备兜底方案。我的兜底策略是分级的:第一优先用页面标题;第二优先用og:title或twitter:title这类元信息(有些页面title是首页,但 og 标签是文章名);第三优先用 URL 的最后一段路径做可读化处理(把-和_换成空格、去掉扩展名);最后兜底用域名加时间戳。这个降级链条写起来不到一百行,但能把列表里一堆空白的观感问题彻底解决。注意:抓取标题时一定要设置User-Agent,不要用默认的脚本 UA,否则被 403 的概率会大幅上升。同时不要把抓到的 HTML 整个读进内存——有些页面体积能到十几兆,正确做法是流式读取,拿到第一个 64KB 就停,标题基本都在这个范围内。4.2 并发数和超时参数到底怎么定这两个参数是巡检效率的核心,拍脑袋设很容易出问题。先说超时:我采用的是分阶段超时,连接超时 3 秒,读取超时 5 秒,整体兜底 10 秒。连接超时短一点是因为连不上通常就是连不上,等 10 秒纯属浪费;读取超时长一点是因为有些站点首字节返回慢,但一旦开始返回就很快。并发数则要算一笔账。假设你有 5000 条链接,单条平均耗时 800 毫秒:并发 4,理论总耗时 5000 ÷ 4 × 0.8 秒 1000 秒,约 17 分钟并发 8,理论总耗时 5000 ÷ 8 × 0.8 秒 500 秒,约 8.5 分钟并发 16,理论总耗时 5000 ÷ 16 × 0.8 秒 250 秒,约 4.2 分钟看起来并发越高越好,但实际情况是:并发超过 16 之后,边际收益急剧下降,因为你面对的是成百上千个不同的目标站点,单个站点的响应速度成为瓶颈,而提高全局并发只会让你更容易触发对方的限速。同时本地文件描述符、DNS 解析队列也会开始成为限制。所以我最终的配置是:全局并发 12,单域名并发 1,单域名最小请求间隔 1 秒。全局并发控制用信号量,单域名控制用一个以域名为键的字典加时间戳。这套组合下来,5000 条链接的全量巡检大概 9 到 12 分钟跑完,同时几乎不会触发任何站点的限速。4.3 死链误判的四种典型场景死链这个词听起来很明确,实际判断起来模糊得很。我最初的做法简单粗暴:状态码不是 200 就算异常。结果第一次跑完,报出来两百多条死链,逐条点开一看,九成是活的。后来总结出四种高频误判:现象真实原因正确处理返回 403站点屏蔽了脚本 UA 或需要登录不算死链,标记为需人工确认返回 429触发了速率限制退避后重试,重试仍 429 则标记暂缓返回 301/302 但不跟随绝大多数正常链接都靠跳转跟随重定向,最多 5 跳,超出才判异常返回 200 但内容为空前端渲染型页面,首屏 HTML 里没内容不能只看状态码,但也不必强判,归为正常还有一个更隐蔽的情况:站点整体更换域名,老域名返回 301 到一个首页而不是具体文章。这种从状态码上完全看不出来,只有在跟随跳转后发现最终 URL 的 path 被重置成了/,才能怀疑。我的做法是记录下跳转后 path 变化超过两级的条目,单独列一个清单人工过一遍,数量一般不大。所以最终的状态机不是死/活两态,而是四态:正常、跳转(记录了新地址)、异常(4xx/5xx 且非上述特例)、待确认(403、429、超时等无法定性的)。只有异常和连续多次待确认的条目才会进入清理候选,而且清理永远是标记而不是删除——删数据这件事,交给人工点确认。4.4 巡检任务的状态机与断点续跑全量巡检跑十几分钟这件事,意味着它一定会被打断:你会关电脑、会切网络、会中途想改配置。所以巡检必须支持断点续跑,而不能每次都从头开始。实现上很简单,但要提前设计:在link表里维护checked_at,巡检时按checked_at升序取前 N 条(把 NULL 排最前),每处理一条就立刻写回结果和时间戳,用一个事务包住。这样无论在哪一刻中断,下次启动都是从最久没检查的那批开始,天然实现了轮转。批大小我设的是 200 条一个事务,太大容易在中断时丢进度,太小则事务开销明显。另外要处理重试队列。待确认状态的条目不能每一轮都原样重跑,否则永远是那几个站点在拖慢整体。我的策略是给每条记录一个retry_count和一个next_check_at,失败一次就把下次检查时间往后推,退避序列用 1 天、3 天、7 天、30 天。推到最后还失败的,基本可以确定是长期性问题(站点关了或者永久屏蔽),转入待确认不再自动重试,等人工处理。5. 数据落地:从单文件 JSON 走到 SQLite 的这条路5.1 单文件 JSON 的天花板在哪这个工具最早我确实是用一个 JSON 文件做的存储,结构就是数组套对象,读进内存、改完整体写回。在几百条的规模下,它的体验好得无可挑剔:随便用编辑器打开就能看,改一行就能修数据,备份就是复制文件,出问题就是回滚文件,简单到极致。但天花板来得很明确。第一个瓶颈是写入的原子性:整体重写文件的过程中如果断电或者进程被杀,你得到的可能是一个被截断的半个 JSON,所有数据一起完蛋。要规避就得写临时文件再重命名,这一步一加,代码复杂度就上来了。第二个瓶颈是检索:几千条记录全部加载进内存再遍历,单次查询也要几十毫秒,而且内存占用随规模线性增长,标签统计这种聚合操作更是每次都要全表扫。第三个瓶颈是并发:两个进程同时写一定会互相覆盖,而你可能同时开着命令行和一个图形界面。我的经验阈值是:记录数超过 2000 条、或者需要支持多进程写入,就应该换 SQLite。低于这个量级,JSON 的简洁性优势完全值得保留。而且这两者并不冲突——我现在的做法是 SQLite 做主存储,同时保留一条导出为 JSON的命令,用于备份和跨工具交流。5.2 表结构设计:三个反常识的取舍除了第 3 章给出的link表和 FTS 表,完整结构还包括标签的三张表和一张巡检日志表。这里有几个当时纠结了很久的取舍,值得单独说说。第一个,标签用关系表还是用逗号分隔的字符串字段。直觉上逗号分隔简单得多,查的时候用LIKE %db%就行。但这样做的两个后果:一是无法建索引,标签越多查询越慢;二是无法做标签重命名,你得 UPDATE 全表并小心处理子串误匹配(把db重命名成database,dbms也会被改掉)。所以我用了标准的三表结构:CREATE TABLE tag ( id INTEGER PRIMARY KEY, name TEXT NOT NULL UNIQUE COLLATE NOCASE ); CREATE TABLE link_tag ( link_id INTEGER NOT NULL REFERENCES link(id) ON DELETE CASCADE, tag_id INTEGER NOT NULL REFERENCES tag(id) ON DELETE CASCADE, PRIMARY KEY (link_id, tag_id) ); CREATE INDEX idx_link_tag_tag ON link_tag(tag_id);ON DELETE CASCADE是关键,它保证删链接时标签关联自动清理,不需要在应用层维护。COLLATE NOCASE保证DB和db不会变成两个标签。第二个,时间用整数时间戳还是文本日期。我最终全部用 Unix 秒级整数。理由是排序、比较、做区间查询都直接对应整数运算,不需要任何日期解析;而文本日期在 SQLite 里做BETWEEN虽然也能用,但一旦混入不同格式(有的带时区有的不带)就会出乱子。展示的时候再格式化成人类可读,这个转换成本可以忽略。第三个,删除用物理删除还是软删除。我选了软删除——加一个deleted_at字段,查询时统一加WHERE deleted_at IS NULL。理由很实在:手滑误删一条存了半年的链接,痛苦程度远超多占几 KB 存储。软删除的数据可以定期清理,比如保留 30 天,或者干脆只在手动执行压缩数据库命令时才真正清除。5.3 导入导出:和浏览器书签、CSV 之间来回倒腾任何链接管理工具,冷启动都得从别处导入。最高频的三个来源是:浏览器导出的书签 HTML、其他工具导出的 CSV、以及一堆直接粘贴的裸 URL 文本。浏览器书签的 HTML 格式是 Netscape Bookmark 格式,结构是一层嵌套的DLDTH3和DTA。解析它不需要引入重量级的 HTML 解析器,但一定要用容错型解析,因为各家导出的文件在闭合标签、编码声明、属性顺序上都有些许差异。我踩过的坑是:某个浏览器导出的文件里A标签的HREF属性写在ADD_DATE后面,如果按固定顺序写正则就会漏匹配。所以属性提取一定要写成挨个找namevalue对,而不是按位置切。至于书签里的目录层级,导入时不要转成多级标签,而是只取最末一级目录名作为一个import:前缀的标签。这样既保留了原始分类的线索,又不至于把一棵三层的目录树硬塞进标签体系里把标签搞爆。导出方面我坚持三条格式同时支持:SQLite 文件(完整备份)、CSV(给人看和给表格软件用)、纯文本清单(一行一条,格式为URL[TAB]标题[TAB]标签1,标签2)。纯文本那份是最重要的,前面说过,它是最后一道保险。CSV 要注意的是字段里的逗号、引号、换行必须正确转义,自己手写拼接字符串几乎一定会出错,用标准库的csv模块,别省这一步。5.4 备份:把文件复制一份这件事做扎实SQLite 的备份有一个必须知道的细节:不能在服务运行中直接cp数据库文件。因为可能有未落盘的事务日志(-wal和-shm文件),单拷主文件会得到一个不完整甚至损坏的副本。正确做法有两种:用sqlite3 db .backup out.db命令,或者对应的备份 API,它会在线生成一致快照。先执行PRAGMA wal_checkpoint(TRUNCATE);把 WAL 合并回主库,再复制。我自己的做法是每天一次自动备份,文件名带日期,保留最近 14 份,超过的自动删除。另外每周做一次逻辑备份(把表导成 SQL 文本),因为逻辑备份不依赖 SQLite 的版本和页格式,几十年后大概还能读。注意:备份一定要验证过再算数。我见过太多次以为有备份,真出事时发现备份文件是 0 字节。最简单的验证方法是每次备份完成后自动跑一次PRAGMA integrity_check,再加上一句SELECT count(*) FROM link,把记录数记到日志里,数字对不上就报警。6. 用下来最该守住的几条规矩,以及我踩过的坑6.1 安全底线:只放行 http 和 https,顺手挡住内网地址这是个个人工具,但它要主动去请求用户输入的地址,所以安全边界的意识不能丢。第一条也是最硬的一条:只接受http和https两种 scheme。javascript:、data:、file:、vbscript:这些必须在校验阶段直接拒绝,尤其是file:——一旦允许,任何一条被污染的链接都可能变成读取本地文件并回显的通道,哪怕你只是想看看标题是什么。第二条是抓取时的私网地址拦截。这是个容易被忽略但很关键的点:当工具拿着用户给的 URL 去发请求时,如果这个 URL 指向127.0.0.1、10.x、172.16~31.x、192.168.x、169.254.x这些内网段,就等于把本机或内网的服务暴露给了这条链接。正确的拦截顺序是:解析 URL 拿到 host;如果是 IP 字面量,直接判断是否落在私网/回环/链路本地段,命中即拒绝;如果是域名,先做 DNS 解析,再对每一个解析结果做同样的判断;用 IP 直连并带上Host头,而不是再按域名连一次——这一步是为了防 DNS 重绑定,即同一个域名第一次解析到公网、第二次解析到内网。第 4 步很多人都省了,省了就等于前面三步白做。实现上多花十几行代码,值得。6.2 有些链接本身就带敏感信息,存之前得先脱敏这一条是我在真实数据里发现的:不少站点会把访问令牌、会话标识、邮箱、手机号直接编码在 URL 里,比如查询串里带token...、signature...、email...这类参数,或者干脆把地址放在路径里。这类链接如果原样入库、原样导出、原样出现在备份文件里,风险是实实在在的。我的处理是入库时做一次参数级脱敏:命中敏感参数名(token、access_token、key、secret、sign、signature、auth、password、sessionid、email、phone)的值,统一替换成固定占位符,同时把这个动作记录下来,提示用户这条链接的部分参数已被屏蔽,原值未保存。这样做会导致这条链接不可直接访问,所以更温和的方案是:原值仍然保存,但导出时默认脱敏,需要原值必须显式加参数。个人用的话我更推荐后一种,因为工具的主要风险面在导出和共享这一环,而不是本地数据库。另外还有一个实践习惯值得养成:不要把包含登录态的链接存进来。我的判断方法是看 URL 长度和参数随机性,超过 500 字符且带多个长随机串的链接,大概率是带会话信息的深链接,这种东西今天能打开、明天就失效,存下来价值极低。6.3 几条用久了才明白的使用习惯工具本身的能力上限不高,真正决定它好不好用的是使用习惯。下面这几条是我用坏过好几轮之后才固定下来的。入库即打标签,哪怕只打一个。当时不打,指望以后统一整理,这基本等于永远不打。我在命令行里把新增命令做成了一条链路:furl add url --tag db --tag st:todo,一条命令解决,零点几秒的事,不给自己留稍后处理的口子。标题允许手动覆盖,而且要能一键改。抓来的标题有相当比例是首页、登录、文档中心这种无信息量的词。这时候手动补一句备注,价值远超任何自动摘要。我的note字段使用频率高得惊人,已经成了最重要的检索字段之一。每周花五分钟清一次st:todo。这一条听起来像自律鸡汤,但实际上是这个工具唯一能防止腐化的机制。待读列表如果一直只增不减,两周之后你就不会再看它了。我的做法是每周固定时间把st:todo过一遍,读过的改st:done,不打算读的直接删标签降级,实在舍不得的加st:archive归档。清完之后待读列表维持在 20 条以内,这个数字是我实测下来还会真的去读的上限。别怕删。早期我有很重的收藏等于拥有的幻觉,存了上千条,访问率不到两成。后来想通了一件事:一条链接如果一年都没有被打开过,它对你的价值大概率是负的——它占用检索空间、干扰结果排序、增加维护心理负担。现在我每季度做一次一年未访问的扫描,批量归档,归档区再放一年,然后彻底清掉。最后分享一个我自己觉得最有用的细节:我给自己加了个furl random --tag st:todo的随机取一条命令,绑在每天早上打开电脑的第一个动作上。它会从待读列表里随机抽一条推给我,比我主动去翻列表有效得多——因为翻列表的时候你会挑简单的看,随机推送才会真的把那些被冷落的链接重新带到面前。这个小功能写完只花了二十行代码,但它是整套东西里我使用频率最高的一条命令,也是让这个 URL 管理工具没有变成又一个数字坟场的关键。 
长河君 · 2026/10/31 8:30:13 · 阅读 1.2k URL清洗到死链巡检：本地链接管理工具设计实践
打开自己的聊天记录搜索栏输入一个关键词翻了十几页,那种又熟悉又陌生的挫败感,大概每个长期在网络上做资料收集的人都经历过。你明明记得三个月前看过一篇非常对症的文章,记得它的配图长什么样,甚至记得当时在哪个上下文里遇到它,唯独找不到那条链接。收藏夹里倒是塞了几百条,可真要找的时候,要么忘了当初给它起了什么名字,要么压根没起名字,只剩一串光秃秃的地址。这也是我后来动手折腾Furl这类 URL 管理工具的根本原因——不是缺一个存链接的地方,而是缺一套能把链接整理干净、检索得到、活得够久的机制。这篇内容会从 URL 清洗、标签体系、检索实现、巡检机制、数据落地形态这几个角度,把一个简洁的 URL 管理工具到底是怎么被设计出来的拆开讲清楚。它适合那些想自己写一个本地工具、或者想把现有收藏夹彻底重构一遍的读者,哪怕你只是用过书签而没写过一行代码,也能从里面找到可以直接照搬的规则和参数。1. 为什么存链接这件小事值得单独做一套工具1.1 链接失序的真实成本,比想象中高得多大多数人管理链接的方式,本质上只有三种:浏览器书签、聊天软件里的发给自己、以及临时记在某个笔记文档里。这三种方式有一个共同的缺陷——入库的成本极低,出库的成本极高。往书签里加一条链接只需要一次点击,但当你有八百条书签的时候,想从里面捞出特定的三条,你付出的检索成本已经远远超过了当初省下的那一次点击。我在做这套东西之前,专门统计过自己的收藏行为:平均每天会新增 6 到 10 条想留存的链接,一个月下来两三百条,三个月就是一个没人敢打开的抽屉。这些链接里,真正会被再次访问的可能只有 15% 左右,但问题在于你事前没法判断哪 15% 有用,所以只能全存,于是全都被淹没。更麻烦的是重复——同一条内容从不同渠道进来,带着完全不同的跟踪参数,系统认为它们是两条,你也被迫在两条之间犹豫。所以一个 URL 管理工具真正要解决的不是存储,而是三个更靠后的问题:入库时把噪音除掉,存储时把结构建好,出库时把入口做短。Furl 这个名字听起来轻,但它的重心其实全在这三件事上,界面反而是最不值钱的部分。1.2 Furl 的定位边界:它明确不做什么把边界说清楚,比把功能罗列一遍有用得多。我在设计 Furl 的时候给自己划了几条硬线,后面所有的技术选择都是这几条线推导出来的:不做云端账号体系。一旦有账号,就有同步冲突、就有数据归属、就有服务停了你的链接怎么办的问题。所有数据落在本地一个文件里,复制走就是完整迁移。不做社交化发现。不做推荐、不做公开主页、不做热门列表。这类功能会立刻把工具从我的资料库变成另一个信息流,而信息流恰恰是问题的源头。不做全自动整理。自动打标签、自动归类听起来很香,但准确率一旦卡在 70% 左右,你就得花更多时间去纠正它,比自己手工打还累。宁可让用户手打两个标签,也不要给一堆似是而非的建议。不追求跨端全覆盖。优先把桌面端的命令行和一份稳定的数据格式做扎实,移动端靠导出和只读浏览解决,而不是每端都做一套半成品。这几条边界带来的直接好处是:整个工具的核心可以压缩到一层 URL 处理逻辑 一个本地数据库 一组命令或快捷键。没有网络依赖的部分占了九成,调试起来极其轻松,也不存在服务不可用这种故障模式。1.3 本地优先这个决定,改变了后面所有的架构很多人会觉得数据存本地只是隐私考虑,其实它对工程结构的影响要大得多。因为数据在本机,你可以肆无忌惮地建索引、跑全文检索、做批量重写,不用担心流量和配额;因为数据在本机,抓取标题、巡检死链这种重操作可以放到后台慢慢跑,失败了大不了重来;也因为数据在本机,备份的责任回到了你自己身上,这一点必须有清醒认知。我个人的做法是三层备份:第一层是数据库文件本身定时快照,第二层是每周导出一次纯文本清单(URL 标题 标签,一行一条),第三层是把这份纯文本同步到另一个物理位置。第三层尤其重要——纯文本清单的意义在于,即使哪天工具本身跑不起来了,你手里仍然有一份人眼可读、任何编辑器都能打开的链接资产,不至于被某个软件的私有格式锁死。这个思路我在后面第 5 章还会展开讲,因为它决定了表结构怎么设计才不至于把自己坑住。2. 链接入库前的清洗关:把 URL 当数据看,而不是当字符串2.1 那些看着有用、其实全是噪音的查询参数从任何渠道复制来的链接,大概率都不是干净的。社交平台、内容平台、搜索引擎、邮件客户端,几乎都会往 URL 后面挂一串跟踪参数。它们的共同特征是:对内容定位毫无作用,但会让同一条内容在数据库里变成好几条不同的记录,并且让链接长到在终端里换行。常见的那几类,我整理成一张表,方便你直接对照自己的数据看:参数类别典型参数名处理建议投放跟踪utm_source、utm_medium、utm_campaign、utm_term、utm_content、utm_id一律丢弃,这类纯属归因用平台渠道spm、scm、share_source、share_medium、share_plat一律丢弃,多见于内容平台分享链接广告点击gclid、fbclid、msclkid、yclid、dclid一律丢弃邮件营销mtm_campaign、mtm_source、hsa_*、pk_*一律丢弃语义模糊ref、from、source、src、via不能硬编码丢弃,部分站点的source是真实内容参数最后一行是大坑。我一开始图省事,把ref、from、source全都塞进了丢弃列表,结果某个站点的图片地址是...?sourcexxx,一清洗全变成 404。后来改成默认保留,命中时才提醒,才把误伤率降下来。这个教训很朴素:凡是语义可能是业务参数的字段,都不该进硬编码黑名单,只能进可配置的软名单。2.2 规范化规则表:大小写、末尾斜杠、锚点、默认端口清洗完查询参数,接下来要处理 URL 的结构部分。这里的依据是 URI 的通用规范,但落地上有一些需要你自己拍板的细节。我实际采用的是这套规则:组成处理规则理由scheme强制小写,仅允许http/https大小写混写在比较时会漏判host强制小写,去掉末尾的点域名本身不区分大小写porthttp:80和https:443的显式端口去掉否则:443和空端口会被判成两条path保留原样,不改大小写;空路径补为/路径在很多服务端是大小写敏感的,改了就 404query参数按键名排序,保留重复键的相对顺序排序后才能稳定判重fragment默认去掉锚点通常不影响内容本身关于 fragment,有一个必须例外的情况:前端路由的页面,内容其实完全由锚点决定,比如#/article/123这种。我的判断逻辑是——如果 path 为空或仅为/,且 fragment 以!或/开头,就保留 fragment;其余情况一律丢弃。这一条规则挡住过我好几次看起来重复但其实是不同页面的误合并。还有两个容易忽略的点。其一是 IPv6 地址:正规写法要求方括号包裹,如果你在拼接 netloc 的时候只取 hostname 会丢掉方括号,导致拼出::1:8080这种非法串。其二是百分号编码:空格到底编成%20还是,不同实现不一样,统一按%20处理、且不重复编码已经编码过的序列,这一条要靠实际数据反复试。2.3 去重到底该按原始串、规范化串还是内容指纹这是整个清洗流程里最需要想清楚的一个决策。三种做法各有代价:按原始串去重,优点是绝对安全、绝不误合并,缺点是几乎没什么用,因为同一条链接的十几个变体会全部留下来。按规范化串去重,是我最终选的方案,平衡点最好——它能吃掉端口、大小写、参数顺序、跟踪参数这些确定性的差异,同时不会改变指向内容本身。按内容指纹去重(先抓页面再算正文哈希),理论上最准,但成本极高:每条链接都要实际请求一次,遇到登录墙、反爬、动态渲染就全都失效,而且删除时机的判断会变得非常复杂。规范化串去重还有一个隐藏好处:它天然给出了一个稳定的主键。我对规范化后的 URL 做一次 SHA-256,截取前 16 个字节的十六进制作为url_key,存进数据库时加唯一约束。这样即使以后更换语言、更换实现,甚至把数据导到另一个工具里去,这个键仍然是确定可复现的,不会出现重新导入一遍全变成重复项的惨剧。2.4 一段可以直接抄走的清洗实现下面的实现是我实际在用的核心逻辑,依赖 Python 标准库,没有第三方依赖,可以直接改改就用:import hashlib from urllib.parse import urlsplit, urlunsplit, parse_qsl, urlencode DROP_PREFIXES (utm_, mtm_, hsa_, pk_) DROP_EXACT { fbclid, gclid, dclid, msclkid, yclid, spm, scm, share_source, share_medium, share_plat, } # 语义模糊的参数不删,仅做记录,留给用户判断 SOFT_HINTS {ref, from, source, src, via} def is_dropped(key: str) - bool: k key.lower() if k in DROP_EXACT: return True return any(k.startswith(p) for p in DROP_PREFIXES) def normalize(raw: str, keep_fragment: bool False) - str: raw raw.strip() parts urlsplit(raw) scheme parts.scheme.lower() if scheme not in (http, https): raise ValueError(funsupported scheme: {scheme}) host (parts.hostname or ).lower().rstrip(.) port parts.port if (scheme, port) in ((http, 80), (https, 443)): port None netloc host if port is None else f{host}:{port} path parts.path or / pairs [(k, v) for k, v in parse_qsl(parts.query, keep_blank_valuesTrue) if not is_dropped(k)] pairs.sort(keylambda kv: kv[0]) # 稳定排序,同键保持原序 query urlencode(pairs, doseqTrue) frag if keep_fragment and (path in (, /)) and parts.fragment.startswith((!, /)): frag parts.fragment return urlunsplit((scheme, netloc, path, query, frag)) def url_key(normalized: str) - str: return hashlib.sha256(normalized.encode(utf-8)).hexdigest()[:16]用法上,入库前先normalize,再算url_key,把url_raw(原始输入)、url_norm(规范化结果)、url_key(去重键)三个字段一起存下来。多存一份原始串的价值在于:万一某条规则把关重要的参数删错了,你还能回溯;而且原始串里往往带着来源信息,后期做渠道分析时用得上。注意:pairs.sort()用的是只按键名排序,这对绝大多数站点没问题,但如果某个接口把参数顺序当语义(罕见但存在),排序会改变行为。我遇到过的一次是某个文件下载接口依赖参数顺序签名,解决办法是对特定域名关闭排序,用一张域名例外表兜底。3. 标签与检索:让三个月后的自己还能把链接找回来3.1 我不推荐无限层级文件夹的三个理由收藏夹天然会演化成文件夹树,而文件夹树有一个几乎无法避免的结局——层级不断加深,分类边界不断模糊。我自己就建过技术/前端/构建工具/打包这种四级路径,建的时候觉得清晰,半年后完全想不起来某个东西当时放在构建工具还是打包下面。第一个理由是专属排他性。一条链接只能属于一个文件夹,但这篇文章可能同时是构建工具和性能优化和值得重读,文件夹逼你选一个,选错就再也找不到。第二个理由是维护成本随深度指数上升。目录一多,你就得不断地搬东西、合并目录、重命名,这些维护工作本身没有任何产出。第三个理由是检索能力被浪费。现代数据库的检索能力早就够用了,你却把分类的工作交给人工目录,等于用最贵的方式做最简单的事。标签体系不一样,一条链接可以挂多个标签,标签之间是并集关系,天然适合我记不清放哪了但我记得它跟什么有关这种真实场景。代价是标签会膨胀,所以需要一个约束机制。3.2 标签命名的一套土办法:前置维度 短词我用了两年多,效果最好的一套规则是维度前缀 短词的双段式命名:类型维度:type:article、type:tool、type:repo、type:video、type:doc状态维度:st:todo、st:done、st:archive、st:broken主题维度:自由短词,如db、css、cli、deploy,一律小写、不超过 12 个字符来源维度:src:newsletter、src:chat、src:search,用来回溯渠道前缀的好处是输入时能靠补全快速筛选——敲st:就只出状态类标签,敲ty就只出类型类,不会在几十个标签里迷路。短词的好处是抑制描述性标签的冲动,db比database-indexing-best-practice有用得多,后者其实是笔记该干的事,放note字段里更合适。还有一条铁律:标签总数控制在 60 个以内。超过这个数,补全列表就开始失去导航价值,你会开始退化成靠记忆输入。我每季度会跑一次标签统计,把出现次数小于 3 的标签挑出来合并或删掉,这个过程大概花十分钟,但能让整个体系保持可用。3.3 三种检索入口,对应三种不同的记忆状态人的记忆状态其实分三种,对应的检索策略完全不同,这也是我把查询入口设计成三套的原因:第一种,你记得开头。这时候前缀匹配最快。用户敲docs.就只出这个域名下的所有记录,敲htt就只出 URL 里以这个开头的。前缀查询一定要做成实时过滤,延迟控制在 50 毫秒以内,否则手感就废了。第二种,你记得某个词但不记得在哪。这时候需要全文检索,而且要同时覆盖标题、URL、备注三个字段。很多人只索引标题,结果链接标题是首页、文档中心这种毫无信息量的词,照样搜不到。把 URL 也纳入索引能救回很多这类情况,因为域名和路径里的词往往比标题更有辨识度。第三种,你记得的条件是组合的。比如去年存的那批关于数据库的文章里还没读的。这时候需要的是条件表达式,而不是关键词。我在 Furl 里做了一个极简的查询语法:tag:db tag:st:todo before:2024-06-01,多个条件之间默认是与关系。实现上不需要写解析器框架,一个正则把字段:值抽取成结构化条件即可,剩下的交给 SQL 拼接。3.4 本地全文检索的落地细节与几个实打实的坑如果选 SQLite 做存储,全文检索直接用 FTS5 就够了。难点不在能不能跑,而在分词。默认的unicode61分词器对中文几乎不可用,它会把一整段连续的中文字符当成一个词,导致你搜任何一个片段都命中不了。解决方案有三个,我按推荐顺序排:trigram分词器(SQLite 3.34 及以上)。把文本切成三元组,对中英文混排效果都不错,而且支持LIKE风格的模糊查询。代价是索引体积会涨到原文本的 3 到 4 倍,查询的字符串长度至少要 3 个字符才有意义。入库前手动切字。把中文按双字切分,用空格连起来,再喂给unicode61。实现简单,但对词语边界的处理比较粗暴。引入外部分词组件。效果最好,但要带一个不小的依赖,和简洁的定位有冲突。我最终用的是 trigram,建表语句大致如下:CREATE TABLE link ( id INTEGER PRIMARY KEY, url_key TEXT NOT NULL UNIQUE, url_raw TEXT NOT NULL, url_norm TEXT NOT NULL, title TEXT, note TEXT, created_at INTEGER NOT NULL, status INTEGER DEFAULT 0, -- 0 未检 1 正常 2 跳转 3 异常 4 消失 checked_at INTEGER ); CREATE VIRTUAL TABLE link_fts USING fts5( title, url_norm, note );这里我用的是独立内容表而不是外部内容表(contentlink),原因是外部内容表的同步要靠触发器维护,一旦有批量更新(比如全量重写规范化 URL)很容易出现索引和主表不一致,而且很难察觉。独立表的代价是多占一份存储、写入时要手动双写,但换来的是所见即所索引的确定性,对个人工具来说这笔账划算。还有一个非常容易踩的坑:trigram 索引下的短语查询。MATCH 数据库 索引这种带引号的短语写法在 trigram 下行为和unicode61完全不同,如果你的查询词是用户随手敲的,记得先做一次转义,把可能被当成 FTS 语法的字符(、*、^、:、(、)、-)处理掉,否则用户搜一个带减号的词就会直接抛语法错误。我在早期版本里因为这个报错崩过好几次。4. 抓标题与死链巡检:并发、限速与误判处理4.1 为什么非抓标题不可,以及抓不到时的兜底策略一条光秃秃的 URL,三个月后你几乎不可能认出它是什么。而一个像样的标题,能让整个列表瞬间变得可扫视。所以入库后异步抓取标题是这类工具的标配功能,但它的失败率比大多数人预想的高得多。我统计过自己那批链接的抓取结果,大致分布是这样的:能成功拿到title的约占 72%,需要跟随重定向才能拿到的占 11%,返回 403/401 的占 6%,超时的占 4%,其余是各种奇怪情况(返回空页、返回 PDF、返回 JS 渲染的空壳)。也就是说接近三成的情况下你抓不到标题,必须准备兜底方案。我的兜底策略是分级的:第一优先用页面标题;第二优先用og:title或twitter:title这类元信息(有些页面title是首页,但 og 标签是文章名);第三优先用 URL 的最后一段路径做可读化处理(把-和_换成空格、去掉扩展名);最后兜底用域名加时间戳。这个降级链条写起来不到一百行,但能把列表里一堆空白的观感问题彻底解决。注意:抓取标题时一定要设置User-Agent,不要用默认的脚本 UA,否则被 403 的概率会大幅上升。同时不要把抓到的 HTML 整个读进内存——有些页面体积能到十几兆,正确做法是流式读取,拿到第一个 64KB 就停,标题基本都在这个范围内。4.2 并发数和超时参数到底怎么定这两个参数是巡检效率的核心,拍脑袋设很容易出问题。先说超时:我采用的是分阶段超时,连接超时 3 秒,读取超时 5 秒,整体兜底 10 秒。连接超时短一点是因为连不上通常就是连不上,等 10 秒纯属浪费;读取超时长一点是因为有些站点首字节返回慢,但一旦开始返回就很快。并发数则要算一笔账。假设你有 5000 条链接,单条平均耗时 800 毫秒:并发 4,理论总耗时 5000 ÷ 4 × 0.8 秒 1000 秒,约 17 分钟并发 8,理论总耗时 5000 ÷ 8 × 0.8 秒 500 秒,约 8.5 分钟并发 16,理论总耗时 5000 ÷ 16 × 0.8 秒 250 秒,约 4.2 分钟看起来并发越高越好,但实际情况是:并发超过 16 之后,边际收益急剧下降,因为你面对的是成百上千个不同的目标站点,单个站点的响应速度成为瓶颈,而提高全局并发只会让你更容易触发对方的限速。同时本地文件描述符、DNS 解析队列也会开始成为限制。所以我最终的配置是:全局并发 12,单域名并发 1,单域名最小请求间隔 1 秒。全局并发控制用信号量,单域名控制用一个以域名为键的字典加时间戳。这套组合下来,5000 条链接的全量巡检大概 9 到 12 分钟跑完,同时几乎不会触发任何站点的限速。4.3 死链误判的四种典型场景死链这个词听起来很明确,实际判断起来模糊得很。我最初的做法简单粗暴:状态码不是 200 就算异常。结果第一次跑完,报出来两百多条死链,逐条点开一看,九成是活的。后来总结出四种高频误判:现象真实原因正确处理返回 403站点屏蔽了脚本 UA 或需要登录不算死链,标记为需人工确认返回 429触发了速率限制退避后重试,重试仍 429 则标记暂缓返回 301/302 但不跟随绝大多数正常链接都靠跳转跟随重定向,最多 5 跳,超出才判异常返回 200 但内容为空前端渲染型页面,首屏 HTML 里没内容不能只看状态码,但也不必强判,归为正常还有一个更隐蔽的情况:站点整体更换域名,老域名返回 301 到一个首页而不是具体文章。这种从状态码上完全看不出来,只有在跟随跳转后发现最终 URL 的 path 被重置成了/,才能怀疑。我的做法是记录下跳转后 path 变化超过两级的条目,单独列一个清单人工过一遍,数量一般不大。所以最终的状态机不是死/活两态,而是四态:正常、跳转(记录了新地址)、异常(4xx/5xx 且非上述特例)、待确认(403、429、超时等无法定性的)。只有异常和连续多次待确认的条目才会进入清理候选,而且清理永远是标记而不是删除——删数据这件事,交给人工点确认。4.4 巡检任务的状态机与断点续跑全量巡检跑十几分钟这件事,意味着它一定会被打断:你会关电脑、会切网络、会中途想改配置。所以巡检必须支持断点续跑,而不能每次都从头开始。实现上很简单,但要提前设计:在link表里维护checked_at,巡检时按checked_at升序取前 N 条(把 NULL 排最前),每处理一条就立刻写回结果和时间戳,用一个事务包住。这样无论在哪一刻中断,下次启动都是从最久没检查的那批开始,天然实现了轮转。批大小我设的是 200 条一个事务,太大容易在中断时丢进度,太小则事务开销明显。另外要处理重试队列。待确认状态的条目不能每一轮都原样重跑,否则永远是那几个站点在拖慢整体。我的策略是给每条记录一个retry_count和一个next_check_at,失败一次就把下次检查时间往后推,退避序列用 1 天、3 天、7 天、30 天。推到最后还失败的,基本可以确定是长期性问题(站点关了或者永久屏蔽),转入待确认不再自动重试,等人工处理。5. 数据落地:从单文件 JSON 走到 SQLite 的这条路5.1 单文件 JSON 的天花板在哪这个工具最早我确实是用一个 JSON 文件做的存储,结构就是数组套对象,读进内存、改完整体写回。在几百条的规模下,它的体验好得无可挑剔:随便用编辑器打开就能看,改一行就能修数据,备份就是复制文件,出问题就是回滚文件,简单到极致。但天花板来得很明确。第一个瓶颈是写入的原子性:整体重写文件的过程中如果断电或者进程被杀,你得到的可能是一个被截断的半个 JSON,所有数据一起完蛋。要规避就得写临时文件再重命名,这一步一加,代码复杂度就上来了。第二个瓶颈是检索:几千条记录全部加载进内存再遍历,单次查询也要几十毫秒,而且内存占用随规模线性增长,标签统计这种聚合操作更是每次都要全表扫。第三个瓶颈是并发:两个进程同时写一定会互相覆盖,而你可能同时开着命令行和一个图形界面。我的经验阈值是:记录数超过 2000 条、或者需要支持多进程写入,就应该换 SQLite。低于这个量级,JSON 的简洁性优势完全值得保留。而且这两者并不冲突——我现在的做法是 SQLite 做主存储,同时保留一条导出为 JSON的命令,用于备份和跨工具交流。5.2 表结构设计:三个反常识的取舍除了第 3 章给出的link表和 FTS 表,完整结构还包括标签的三张表和一张巡检日志表。这里有几个当时纠结了很久的取舍,值得单独说说。第一个,标签用关系表还是用逗号分隔的字符串字段。直觉上逗号分隔简单得多,查的时候用LIKE %db%就行。但这样做的两个后果:一是无法建索引,标签越多查询越慢;二是无法做标签重命名,你得 UPDATE 全表并小心处理子串误匹配(把db重命名成database,dbms也会被改掉)。所以我用了标准的三表结构:CREATE TABLE tag ( id INTEGER PRIMARY KEY, name TEXT NOT NULL UNIQUE COLLATE NOCASE ); CREATE TABLE link_tag ( link_id INTEGER NOT NULL REFERENCES link(id) ON DELETE CASCADE, tag_id INTEGER NOT NULL REFERENCES tag(id) ON DELETE CASCADE, PRIMARY KEY (link_id, tag_id) ); CREATE INDEX idx_link_tag_tag ON link_tag(tag_id);ON DELETE CASCADE是关键,它保证删链接时标签关联自动清理,不需要在应用层维护。COLLATE NOCASE保证DB和db不会变成两个标签。第二个,时间用整数时间戳还是文本日期。我最终全部用 Unix 秒级整数。理由是排序、比较、做区间查询都直接对应整数运算,不需要任何日期解析;而文本日期在 SQLite 里做BETWEEN虽然也能用,但一旦混入不同格式(有的带时区有的不带)就会出乱子。展示的时候再格式化成人类可读,这个转换成本可以忽略。第三个,删除用物理删除还是软删除。我选了软删除——加一个deleted_at字段,查询时统一加WHERE deleted_at IS NULL。理由很实在:手滑误删一条存了半年的链接,痛苦程度远超多占几 KB 存储。软删除的数据可以定期清理,比如保留 30 天,或者干脆只在手动执行压缩数据库命令时才真正清除。5.3 导入导出:和浏览器书签、CSV 之间来回倒腾任何链接管理工具,冷启动都得从别处导入。最高频的三个来源是:浏览器导出的书签 HTML、其他工具导出的 CSV、以及一堆直接粘贴的裸 URL 文本。浏览器书签的 HTML 格式是 Netscape Bookmark 格式,结构是一层嵌套的DLDTH3和DTA。解析它不需要引入重量级的 HTML 解析器,但一定要用容错型解析,因为各家导出的文件在闭合标签、编码声明、属性顺序上都有些许差异。我踩过的坑是:某个浏览器导出的文件里A标签的HREF属性写在ADD_DATE后面,如果按固定顺序写正则就会漏匹配。所以属性提取一定要写成挨个找namevalue对,而不是按位置切。至于书签里的目录层级,导入时不要转成多级标签,而是只取最末一级目录名作为一个import:前缀的标签。这样既保留了原始分类的线索,又不至于把一棵三层的目录树硬塞进标签体系里把标签搞爆。导出方面我坚持三条格式同时支持:SQLite 文件(完整备份)、CSV(给人看和给表格软件用)、纯文本清单(一行一条,格式为URL[TAB]标题[TAB]标签1,标签2)。纯文本那份是最重要的,前面说过,它是最后一道保险。CSV 要注意的是字段里的逗号、引号、换行必须正确转义,自己手写拼接字符串几乎一定会出错,用标准库的csv模块,别省这一步。5.4 备份:把文件复制一份这件事做扎实SQLite 的备份有一个必须知道的细节:不能在服务运行中直接cp数据库文件。因为可能有未落盘的事务日志(-wal和-shm文件),单拷主文件会得到一个不完整甚至损坏的副本。正确做法有两种:用sqlite3 db .backup out.db命令,或者对应的备份 API,它会在线生成一致快照。先执行PRAGMA wal_checkpoint(TRUNCATE);把 WAL 合并回主库,再复制。我自己的做法是每天一次自动备份,文件名带日期,保留最近 14 份,超过的自动删除。另外每周做一次逻辑备份(把表导成 SQL 文本),因为逻辑备份不依赖 SQLite 的版本和页格式,几十年后大概还能读。注意:备份一定要验证过再算数。我见过太多次以为有备份,真出事时发现备份文件是 0 字节。最简单的验证方法是每次备份完成后自动跑一次PRAGMA integrity_check,再加上一句SELECT count(*) FROM link,把记录数记到日志里,数字对不上就报警。6. 用下来最该守住的几条规矩,以及我踩过的坑6.1 安全底线:只放行 http 和 https,顺手挡住内网地址这是个个人工具,但它要主动去请求用户输入的地址,所以安全边界的意识不能丢。第一条也是最硬的一条:只接受http和https两种 scheme。javascript:、data:、file:、vbscript:这些必须在校验阶段直接拒绝,尤其是file:——一旦允许,任何一条被污染的链接都可能变成读取本地文件并回显的通道,哪怕你只是想看看标题是什么。第二条是抓取时的私网地址拦截。这是个容易被忽略但很关键的点:当工具拿着用户给的 URL 去发请求时,如果这个 URL 指向127.0.0.1、10.x、172.16~31.x、192.168.x、169.254.x这些内网段,就等于把本机或内网的服务暴露给了这条链接。正确的拦截顺序是:解析 URL 拿到 host;如果是 IP 字面量,直接判断是否落在私网/回环/链路本地段,命中即拒绝;如果是域名,先做 DNS 解析,再对每一个解析结果做同样的判断;用 IP 直连并带上Host头,而不是再按域名连一次——这一步是为了防 DNS 重绑定,即同一个域名第一次解析到公网、第二次解析到内网。第 4 步很多人都省了,省了就等于前面三步白做。实现上多花十几行代码,值得。6.2 有些链接本身就带敏感信息,存之前得先脱敏这一条是我在真实数据里发现的:不少站点会把访问令牌、会话标识、邮箱、手机号直接编码在 URL 里,比如查询串里带token...、signature...、email...这类参数,或者干脆把地址放在路径里。这类链接如果原样入库、原样导出、原样出现在备份文件里,风险是实实在在的。我的处理是入库时做一次参数级脱敏:命中敏感参数名(token、access_token、key、secret、sign、signature、auth、password、sessionid、email、phone)的值,统一替换成固定占位符,同时把这个动作记录下来,提示用户这条链接的部分参数已被屏蔽,原值未保存。这样做会导致这条链接不可直接访问,所以更温和的方案是:原值仍然保存,但导出时默认脱敏,需要原值必须显式加参数。个人用的话我更推荐后一种,因为工具的主要风险面在导出和共享这一环,而不是本地数据库。另外还有一个实践习惯值得养成:不要把包含登录态的链接存进来。我的判断方法是看 URL 长度和参数随机性,超过 500 字符且带多个长随机串的链接,大概率是带会话信息的深链接,这种东西今天能打开、明天就失效,存下来价值极低。6.3 几条用久了才明白的使用习惯工具本身的能力上限不高,真正决定它好不好用的是使用习惯。下面这几条是我用坏过好几轮之后才固定下来的。入库即打标签,哪怕只打一个。当时不打,指望以后统一整理,这基本等于永远不打。我在命令行里把新增命令做成了一条链路:furl add url --tag db --tag st:todo,一条命令解决,零点几秒的事,不给自己留稍后处理的口子。标题允许手动覆盖,而且要能一键改。抓来的标题有相当比例是首页、登录、文档中心这种无信息量的词。这时候手动补一句备注,价值远超任何自动摘要。我的note字段使用频率高得惊人,已经成了最重要的检索字段之一。每周花五分钟清一次st:todo。这一条听起来像自律鸡汤,但实际上是这个工具唯一能防止腐化的机制。待读列表如果一直只增不减,两周之后你就不会再看它了。我的做法是每周固定时间把st:todo过一遍,读过的改st:done,不打算读的直接删标签降级,实在舍不得的加st:archive归档。清完之后待读列表维持在 20 条以内,这个数字是我实测下来还会真的去读的上限。别怕删。早期我有很重的收藏等于拥有的幻觉,存了上千条,访问率不到两成。后来想通了一件事:一条链接如果一年都没有被打开过,它对你的价值大概率是负的——它占用检索空间、干扰结果排序、增加维护心理负担。现在我每季度做一次一年未访问的扫描,批量归档,归档区再放一年,然后彻底清掉。最后分享一个我自己觉得最有用的细节:我给自己加了个furl random --tag st:todo的随机取一条命令,绑在每天早上打开电脑的第一个动作上。它会从待读列表里随机抽一条推给我,比我主动去翻列表有效得多——因为翻列表的时候你会挑简单的看,随机推送才会真的把那些被冷落的链接重新带到面前。这个小功能写完只花了二十行代码,但它是整套东西里我使用频率最高的一条命令,也是让这个 URL 管理工具没有变成又一个数字坟场的关键。