打开浏览器收藏夹里面躺着一两百个链接真正常用的不超过十个换个设备收藏夹一片空白想找个网站还得打开搜索引擎重新翻半天。我相信不少人都被这个问题折磨过。我就是被折磨多了才正儿八经搞了一套属于自己的网址大全不是那种塞了几百个链接就完事的导航站而是按我的使用习惯重新整理、筛选、维护了快两年的个人网址库。这篇文章就把我这套东西的完整思路和实操过程拆开讲讲从分类体系怎么搭、数据用什么格式存、页面怎么组织到网站筛选标准、失效链接怎么巡检、目录怎么持续维护全部摊开来说。想自己搞一套网址导航的朋友无论你是打算做成网页还是就用一个 Markdown 文件管理这里面的大多数逻辑都能直接抄。1. 把网址大全当产品做而不是当链接表做很多人的网址大全做着做着就废了原因只有一个把它当成了收集链接的地方而不是解决查找效率的地方。这两个出发点导致的结果天差地别。1.1 信息过载时代导航的核心问题不是多而是找2010 年前后是网址导航站的黄金年代那时候上网入口少一个聚合页面能解决大部分需求。现在情况完全反过来了——每个人手机里几十个 App浏览器收藏夹几百个书签公司内部系统一堆地址真正的问题是我知道这个网站存在但我找不到它躺在哪个角落。所以我自己做网址大全时定的第一个原则就是这玩意儿的第一价值是找得到第二价值才是内容全。一个目录如果收录了一千个网站但查起来费劲那它连十个精选链接都不如。这也是为什么搜索引擎没有取代导航页——搜索需要你记得关键词而导航解决的是我记得有这么个东西但说不清名字的模糊检索场景。那找得到靠什么实现靠两件事一是科学的分类二是快。分类让人能按直觉层层下钻搜索框让人能一击命中。我后面 1.2 和 1.3 会分别展开讲这两个方向的设计思考。1.2 分类逻辑按使用场景分而不是按网站类型分刚开始整理网址时我犯过一个典型错误按网站类型分类比如新闻类工具类娱乐类结果发现一个网站根本没法归到单一类别里。比如知乎你说它是社区还是知识库GitHub是代码托管还是学习资源B 站是视频网站还是学习平台分类一交叉就乱套。后来我把整个体系推倒重来改用使用场景作为第一层分类维度。这个思路的来源其实很朴素我打开网址大全的瞬间脑子里想的不是我要找新闻类网站而是我要查资料我要写周报我要找素材我要开会。场景就是你当时要办的事顺着场景去找工具是符合直觉的。我现在的大类大概是这样的工作效率、学习研究、编程开发、设计素材、数据分析、生活服务、影音娱乐、个人管理。每一类下面再挂具体条目。这里有个细节值得说大类的数量要克制7 到 9 个是上限。超过九个第一屏就放不下人眼的扫描成本急剧增加。我见过有人分了二十多类光看侧边栏就得滚动三次这种导航基本是废的。1.3 标签体系给网址加多个维度的检索入口光靠分类还不够因为分类是单一路径而一个网址可能有多个属性。解决办法就是标签。我每条网址可以挂多个标签比如docsify这个文档工具我既给它打文档工具标签也打静态站点和前端标签。搜索时分类和标签的组合就能实现精准过滤。比如我想找一个能配合 GitHub 使用的中文文档工具在搜索框里输入关键词系统同时匹配标题、描述、分类名和标签基本一次就能命中。这套逻辑用过 Notion 或 Obsidian 的人应该秒懂本质上就是文件夹 标签的双轨制。这里给一个实操建议每个网址至少挂三个标签其中一个必须是用途类标签比如查资料做图一个是工具类型标签比如在线工具自托管一个是场景类标签比如移动端协作。这样无论你从哪个角度回忆这个网站都能有一条路径触达它。2. 网址数据怎么管格式、字段与存储方案分类和标签是上层设计落到执行层面就要解决一个问题这些网址数据用什么格式记录、存在哪里、怎么维护。这一步没做好前面设计得再漂亮也是空中楼阁。2.1 数据格式选型JSON、Markdown 还是数据库我个人强烈推荐用JSON 存储元数据 用脚本生成展示页面的组合方案。为什么不用数据库因为网址大全的本质是只读数据没有复杂的关联查询和写入并发杀鸡用不着牛刀。为什么不用纯 Markdown 列表因为 Markdown 不适合承载结构化字段——你没法方便地给每条记录加标签、加描述、加最后检查日期。一条网址记录在我的 JSON 文件里长这样{ id: 001204, name: MDN Web Docs, url: https://developer.mozilla.org/zh-CN/, desc: Web 标准权威文档HTML/CSS/JS 查询首选, category: 编程开发, tags: [文档, 前端, 开发查询], importance: 5, lastChecked: 2025-01-18, notes: 支持中文页面改版后搜索更顺了 }字段不多但每个都有用。desc是给自己看的写的是这个网站是干嘛的将来列表页鼠标悬停就能显示importance是我自己加的优先级参数1 到 5决定排序权重lastChecked是巡检记录后面讲维护时会专门说notes用来记使用心得比如注册才能下载移动端布局有问题这类信息。2.2 存储的位置和备份策略我选择的存储方式是JSON 文件放在 Git 仓库里管理。好处显而易见——所有修改都有历史记录哪天手滑删了一批网址git 回滚就完事了换了电脑clone 一下就是完整的一套还能在多个设备间同步配合 GitHub 的私有仓库顺手解决多设备一致性的问题。备份方面我的策略很朴素Git 仓库本身是一层备份再定期导出成一个 HTML 书签文件放在网盘里。为什么还要 HTML 书签因为通用性最强任何浏览器都能导入万一哪天我的导航站挂了或者不想用这个方案了这些数据还能无缝迁移。我的经验是凡是数据必须有两种以上互不依赖的导出格式兜底这是我被数据丢失坑过之后总结出来的铁律。2.3 从数据到页面静态生成的思路数据用 JSON 存了最终还是要给人看的。我的做法是写一个简单的构建脚本读取 JSON然后按分类生成静态 HTML 页面。为什么要静态页面而不是动态站点最核心的理由是零维护成本。不用装 PHP 或 Node 运行时不用配数据库生成的 HTML 找个静态托管一扔就能访问十几年不过期。另外一个理由是速度纯静态页面打开就是秒开不会因为服务端故障挂掉。脚本的逻辑不复杂核心其实就是三个步骤读 JSON → 按 category 分组并按 importance 排序 → 套模板输出 HTML。顺着这个思路哪怕你用最简单的 Python 脚本甚至 Excel 都能实现关键不在技术选型在于数据与展示剥离这个设计原则——数据是数据的格式展示是展示的逻辑将来换皮肤换布局数据文件一行都不用改。3. 网址筛选标准宁缺毋滥的收录原则目录结构搭好了格式定了接下来就是往里填内容这个看似简单实则最容易翻车的环节。如果筛选用看着有用就收的标准三个月后你的导航站就会变成一个臃肿的垃圾场。3.1 收录的四条硬性标准我给自己定了四条收录标准凡是新加入的网址必须同时满足才收缺一不可高频使用或高价值要么是每周至少会打开一次的工具要么是关键时刻能救急的高价值资源比如正版软件下载渠道、权威数据源那种偶尔可能会用到的一律先放观望区。信息质量可靠内容类网站要来源清晰、更新稳定工具类网站要有明确的维护方或长期运营迹象。对那些内容东拼西凑、来源不明的网站功能再强大我也拒绝。界面可用不是要求多好看而是要求不反人类。弹窗广告糊脸、跳转下载站、注册才能看正文的除非没有替代品否则直接 pass。有不可替代性如果这个网站的活另一个已有收录的网站完全能干那就不收。保持目录干净本质上是在降低后续每一次查找的决策成本。说实话第四条是我后来加上去的。早期我的目录膨胀到六百多条就是因为同样的功能收了七八个替代品结果每次找工具都要纠结用哪个反而更累了。3.2 分类容量控制每个分类多少条合适我给每类设了个软上限核心分类不超过 40 条一般分类不超过 25 条。超过这个数说明不是该收窄收录标准了就是该拆子分类了。举个真实例子我的编程开发类一度塞了 70 多个链接工具从 API 调试到日志分析全混在一起。后来拆分成了开发文档编码工具调试测试部署运维开源项目五个子分级每个子类重新按标准筛选删掉了一大批用过一次就再没碰过的工具。拆分完的体验提升立竿见影——以前要在七十几个条目里找 API 工具现在两步就到达了。这个容量控制的方法其实来自一个很朴素的认知导航页和人脑的记忆一样能快速调用的条目是有限的。你给用户包括你自己展示的选项越少决策成本就越低。这不是我的原创但我在实际整理中确实验证了这个规律。3.3 暂存区机制不要急着收录新网站现在我看上某个新网站第一反应不是立刻加进正式目录而是把它扔进一个暂存区。这个暂存区可以是 JSON 文件里的一个临时数组可以是浏览器书签的一个文件夹甚至可以是笔记软件里的一条待处理清单。两周之后再看这个网站的使用记录如果这两周里我主动访问了三次以上说明它是真需求转正如果只打开过一次甚至基本没碰说明当时只是新鲜感作祟直接删掉。这套机制帮我挡掉了至少一半的无效收录也让我对什么才是真正需要的东西有了更清醒的认知。4. 页面组织与展示我自己这套导航怎么落地前面说的都是数据和筛选现在讲讲最终呈现出来的样子。我的页面组织原则其实就三个字快、清、稳。4.1 首页布局把最常用的放在伸手可及的地方首页只放两类东西搜索框和最核心的分类入口。底下分两栏左边是高频直达区是我使用频率最高的二十个网站按图标加名称的卡片形式排成两排基本上每天开浏览器都会点开几个右边是完整分类索引九个分类用文字链排列不占地方。为什么高频直达区不做成带 logo 的大图标因为我试过图标版好看是好看但维护成本高——每个网站加 logo 都要处理图片新网站收录时必须配图无形中拉高了收录门槛。文字链接虽然没有那么炫酷但胜在轻量、加载快、收录时零成本。搜索框是我自己最依赖的功能。我只在标题和描述字段上做模糊匹配不做全文索引因为网址库本身就几百条的量级全文搜索反而会匹配出大量不相干内容。搜索逻辑很简单不涉及算法但配合标签后效果出乎意料地好大多数场景下点两下鼠标或者敲两个字母就能找到目标网址。4.2 分类页的设计细节分类页和首页是两种形态。首页是快速查找层分类页是浏览发现层。进入某个分类后我按 importance 排序展示所有条目每条包括网站名、URL、一句描述和标签信息。描述这行字很关键我的写法是xxx 工具用于做 xxx优点是 xxx一句话交代清楚它的定位用户不用点进去才知道里面是什么。标签在分类页里显示成小字后缀点击标签还能在当前分类内进一步过滤。这个交互我在没有写一行前端代码的情况下用纯 CSS 加几个 checkbox 就实现了——不是非得上 React 才能做导航站简单的场景用简单的手段反而更稳。另外我特意在底部保留了一个新增与更新区块按时间倒序展示最近加入的网站。这是个给回来看看的机制每次打开导航站先看看这里有什么新东西也算是一种小小的新鲜感。4.3 移动端适配与多设备同步我的导航站没有做独立 App响应式布局其实就够用了。移动端的核心诉求只有一个搜索框要大、要醒目。我在移动端把搜索框固定在页面顶部搜索命中列表直接全屏展示实现方式也极其简单几十行 CSS 的媒体查询就搞定了。多设备同步这块因为数据源是 Git 仓库我的同步路径是电脑上改了 JSON → push → 服务器自动拉取并重新生成静态页面 → 手机浏览器打开就是最新版。这套流程看起来有点绕但稳定性极高而且每一步都是免费工具搭的。如果你不想用 Git也有更简单的方案把 JSON 文件丢在坚果云或任何支持 WebDAV 的网盘里脚本里加一步下载再构建效果一样。5. 常见问题与排查实录做这套网址大全快两年踩过的坑不少。挑几个最有代表性的问题按现象—原因—解法的格式记录在这里你们如果也自己维护导航大概率会碰到同款。5.1 链接失效的三种典型场景链接失效是网址大全最普遍的翻车现场我自己归纳下来主要有三种情况失效类型典型特征排查方法站点改版换域名原链接 404但在搜索引擎能找到新地址把失效链接的关键词丢进搜索通常第一条就是新域名页面迁移到子目录首页还在但具体页面路径变了先访问根域名再按站内结构手动找对应页面站点彻底关停域名打不开搜索引擎也无有效快照用 Wayback Machine 看历史快照确认是否彻底关闭然后找替代品针对这三类问题我的巡检策略是每季度跑一遍所有链接的 HTTP 状态码。方法很土但很有效——写个脚本用 requests 库循环请求凡是状态码不低于 400 的都拉出来人工复核。脚本本身不值一提真正花时间的是对失效链接做处置决策换新地址、标记为站点已迁移、或者直接删除。5.2 分类越整越乱怎么收敛这是维护周期拉长之后的必然问题。刚开始分类很清爽但随着收录数量增长同一个类目下会慢慢长出各种次生需求然后你忍不住给它加个子分类加着加着原来的结构就面目全非了。我的收敛方法叫季度重构每三个月挑一个周末把分类体系从头过一遍。核心动作有三个一是看每个分类的条目数是否超出软上限二是看是否存在可以合并也不会产生混淆的子分类三是检查每个分类的名称是否符合直觉——我会让不懂这套体系的人看一眼目录问他们能不能猜到自己要找的东西在哪个分类下凡是猜不中的分类名都是需要改的信号。比如我当初有个杂七杂八分类后来发现这个分类存在的本身就是一个信号说明我偷懒了没有认真思考某些网站的归属。狠下心把这个分类清空后每个网站都找到了更合理的去处整体结构反而更加紧致了。5.3 多人共用一套导航时的冲突如果你不是一个人用而是团队或者家庭共用一份网址大全会遇上统一性的问题。两个人的使用频率不一样对常用的定义也不一样刚开始还好时间一长就会有人在你不注意的时候自己动手加了链接分类秩序就被打乱了。我的建议是如果一定要多人共用那就把个人区和公共区彻底分开。公共区是大家共同维护的收录标准和管理规则写成文档贴在页面底部明确新增要经过什么流程个人区则是谁想怎么加就怎么加互不干扰。数据上可以分两个 JSON 文件公共区走审核机制哪怕只是拉群说一声个人区完全自治。这套规则一开始就要定好不要等人多了再补补规则永远比定规则麻烦十倍。6. 巡检脚本与自动化维护心得最后专门讲讲维护自动化。网址大全这东西建起来只是一个开始真正的成本在以后每个月、每个季度的维护上。不做好自动化这事儿坚持不下来。6.1 链接可用性巡检的实现思路我用脚本做的定期检测实现逻辑不复杂核心就三步。第一步读取 JSON 里的所有 url第二步用requests.head()发请求设置五秒超时拿状态码第三步把状态码异常的链接输出成一个报告文件标出状态码和网站名供我人工复核。这里有几个实操细节必须说一定要设置超时参数。不设超时的请求可能在某个半死不活的站点上挂几分钟几百个链接巡检下来几个小时就没了设置成 3 到 5 秒超过直接按异常处理。有些网站会屏蔽 HEAD 请求返回 405。这种情况我会改用 GET 请求但限制只取响应头用streamTrue配合response.close()避免下载完整内容。重定向默认是允许的但要手动跟随。某些站点会先 302 到中间页再 302 到最终页多跳几次就不稳定了所以我的脚本里对超过两次重定向的链接也打上标记提示人工检查目标是否正常。6.2 靠 cron 定时触发不靠人肉记忆巡检频率我定的是每个月跑一次全量每周跑一次高频直达那二十条精选链接。后者的意义在于最常用的入口一旦失效影响面最大必须第一时间发现。定时任务用系统自带的 cron 就够不用引入额外工具。每月巡检的完整流程是cron 在每月 1 号凌晨触发 Python 脚本 → 脚本扫描全部链接 → 生成校验报告 → 报告推送到我的邮箱。第二天上班我只要看一眼邮件就知道这个月有哪些链接需要处理。整个过程人肉参与不超过十分钟。6.3 让我效率提升最大的一条经验如果只能给出一条建议我会说不要把链接可靠性寄托在手工记忆上让脚本替你盯着把自己从记得检查这件事里解脱出来。很多人的网址导航最后沦为死链合集不是因为不会检查而是因为总忘记检查而自动化就是专门解决遗忘这个问题的。除了链接检测我还自动化了一个小功能每周导出一次全书签的 HTML 备份丢到网盘目录里。这个动作虽然低频但每次系统重装、换电脑的时候都是它救了我。维护导航站两年最深的体会就是做好备份和自动化剩下的才是筛选和分类这些看起来更有技术含量的事。网址大全做起来不难难的是让它一直好用下去。我见过太多人兴致勃勃地搭了一个导航站两三个月后就再也不更新了。这玩意儿说到底是个养成类项目靠的不是一时的热情而是持续投入的耐心。我在实际维护中最受益的一个习惯是每次发现一个网站特别好用不是顺手收藏就完事而是花三十秒把它按规范录入 JSON加上描述、打上标签、标好优先级。三十秒的即时投入远远小于将来花十分钟从收藏夹废墟里往外捞它的代价。希望能给想动手做一套自己的网址大全的朋友一点实际参考。
