我自己的导航页从“能用”到“好用”前前后后折腾了大半年踩过的坑估计能写满一个记事本。这次我把整个思路、部署细节、二次开发优化和遇到的各种问题一次性整理出来从给家里老人用的极简版到我自己日常重度使用的效率版完整还原整个过程。如果你也想搭一个属于自己的导航页或者对现有的导航页不太满意这篇文章应该能让你少走不少弯路。这个自建导航页的核心思路很简单用 Docker 部署固定的服务端前端页面完全自定义操作系统无关、重装无忧所有配置要么挂载到宿主机要么走环境变量注入。说白了就是把它当成一个正经的互联网服务来对待而不是像个临时脚本一样随手一扔。好处也明显换电脑、迁移服务器、系统重灌以后一条 docker-compose up -d 就能全部恢复原样。1. 项目定位与整体设计思路很多人觉得导航页不就是个收藏夹网页版吗随便找个在线导航网站就够了干嘛要自己折腾。这个想法我一开始也有直到我发现自己收藏夹里躺着的几百个链接真正能在一屏之内快速点到的其实不到二十个。在线导航网站虽然方便但布局是别人定死的图标、分组、排序、搜索都不够顺手更别提还有广告和隐私问题。1.1 核心需求拆解先想清楚你到底要什么动手之前我花了整整一个周末去梳理自己的真实需求最后总结成了四个必须满足的硬性条件第一是快。我需要的不是花里胡哨的页面而是输入网址之后从浏览器收藏夹点到目标站点这个过程足够快。说得直白一点如果导航页加载要超过两秒我宁可直接在地址栏敲域名。第二是分类合理。我日常需要访问的站点可以分成工作、开发、生活、工具、资讯几个大类每个大类下面又有十几个子项。没有分类的导航页就是一团乱麻根本起不到导航的作用。第三是能公网访问。我在家、在公司、甚至在外地用手机都希望能访问同一个导航页这样收藏和配置只需要维护一份。第四是可扩展。网址经常要增删改我希望能做到改一个配置文件或者点几下界面就能完成而不是每次都要改代码、重新部署。把这四个需求列出来之后整个项目的技术选型就明朗了。快意味着页面必须是纯静态的不要动不动就加载一堆 JS 框架。分类合理意味着数据层和展示层要分离不能把链接数据写死在 HTML 里。公网访问意味着要部署在一台公网服务器上或者用内网穿透把服务暴露出去。可扩展意味着要么有完善的后台管理界面要么配置文件的组织方式足够友好。1.2 为什么选择自建而非直接用现成导航站市面上的在线导航产品其实不少Hao123 这类老牌导航站、各种新式导航主页产品我都用过但始终觉得隔靴搔痒。先说到底层原因。在线导航站的盈利模式决定了它们必须在页面上塞满广告位和各种推广链接你打开页面看到的第一屏往往不是你最常用的网站而是对方最能赚钱的网站。UI 上的广告位倒是次要的真正让我受不了的是布局不可定制我把某个类别的顺序调整一下、把某个不用的栏目彻底删掉这些操作在线导航站通通做不到因为它们面向的是大众市场只能提供一套通用模板。自建导航页的核心优势在于一切皆可定制。我可以把每天必用的十来个网站放到首屏黄金位置可以把不常用的工具站点折叠起来不占视线甚至可以把某个特定项目的测试环境地址单独列一组。这种自由度在线导航产品想都不用想。自建还有一个隐形好处是隐私。在线导航页会记录你的浏览习惯和常用站点用于用户画像和广告推荐。自己托管一个导航页所有配置都掌握在自己手里不存在第三方偷偷收集数据的风险。虽然站在个人用户角度这可能不算什么大问题但对在意隐私的人来说这个区别还是实实在在的。1.3 技术方案选型Docker 到底解决了什么问题我最终选择的技术栈是 Docker Compose 加 Nginx 加静态页面中间用 JSON 文件管理链接数据前端用原生 JavaScript 做动态渲染。整个方案没有引入复杂的框架部署和运维都很轻量。这里要重点说说 Docker 这个选择背后的逻辑。我的导航页最初只是放在自己电脑上跑的一个小项目后来想部署到服务器上发现环境配置特别烦人服务器系统版本不一样、Nginx 版本不一样、Node 环境有没有都得重装一遍。用 Docker 之后整个服务被封装成一个标准化的镜像不管底层操作系统是什么只要装了 Docker 就能跑起来这就把“在我电脑上明明能跑”这个经典问题直接绕过了。还有一层考虑是数据持久化。导航页的链接配置、访问统计、自定义布局这些数据如果不做持久化容器一删就全没了。我在设计 Docker Compose 编排文件时特意把配置文件目录和日志目录挂载到宿主机上这样即使容器出问题重建数据和配置也毫发无损。这套思路后来也被我用到其他自建服务上算是意外收获。1.4 整体架构设计与目录规划整个项目跑起来的目录结构大概是这样的nav/ ├── docker-compose.yml ├── nginx/ │ ├── nginx.conf │ └── conf.d/ │ └── nav.conf ├── data/ │ ├── links.json │ ├── settings.json │ └── assets/ │ └── favicon/ └── web/ ├── index.html ├── css/ │ └── style.css └── js/ ├── main.js └── api.jsdocker-compose.yaml 负责服务编排Nginx 做静态文件服务器和反向代理data 目录放所有可变数据web 目录放纯静态的前端页面。这套架构的好处是层次分明数据和代码分离配置和逻辑分离任何时候想替换前端主题只需要动 web 目录不需要碰数据。2. 核心功能拆解与关键技术点导航页听起来是个很简单的应用但真正做起来会发现有不少细节值得琢磨。我在开发过程中把功能拆解成了几个独立模块每个模块解决一类具体问题这样实现起来思路清晰后期维护也方便。2.1 三栏布局与多级分组多种模式的平衡取舍导航页的布局方式直接决定了用户的使用效率。我一开始试过单栏的长列表垂直滚动特别长找东西不方便。后来改成双栏稍微好一点但屏幕利用率还是不够。最终定下来的是三栏自适应布局左边一栏放最常用的工具和开发站点中间一栏放工作相关的平台和信息右边一栏放生活类站点和资讯门户。这里有一个取舍要说明三栏布局在 1920 像素宽度以上的屏幕上体验很好内容一目了然但在笔记本上就有点挤。我的解决方法是做响应式断点屏幕小于 1280 像素时自动降为两栏小于 768 像素时降为单栏并收起分组列表。通过媒体查询来实现这个效果实测下来在手机浏览器上打开也能用虽然不如桌面端方便但至少不至于完全不可用。每个分组内部支持折叠展开默认展开前两个高频分组其余分组折叠起来只显示分类名称。这样首屏的视觉负载就大大降低了用户不会被十几个分组同时堆在眼前的信息淹没。折叠状态的记忆我用 localStorage 实现用户调整过一次之后刷新页面、换个设备再打开分组状态都能保持住。2.2 JSON 配置驱动前后端分离的基础思路数据层是我花心思最多的地方。链接数据不写死在 HTML 里也不用数据库而是一个 JSON 文件。这个文件以数组嵌套对象的形式把分组和链接的关系表达出来大概是下面这个样子{ groups: [ { id: dev, name: 开发工具, icon: code, links: [ { title: GitHub, url: https://github.com, icon: github }, { title: Stack Overflow, url: https://stackoverflow.com, icon: stackoverflow } ] } ] }为什么选 JSON 而不是 SQLite 或者别的数据库原因很简单导航页的链接数据量级通常不会超过几百条这个规模用 JSON 文件管理可读性比数据库高得多修改也方便直接编辑文件或者通过简单的管理接口就能完成。而且 JSON 本身就是 JavaScript 的原生对象表示法前端拿到之后直接就是可用的数据不需要经过 ORM 转换等于省掉了一层数据转换开销。当然JSON 方案也有个劣势就是并发写入能力差。如果多个人同时修改链接配置可能会出现后写覆盖先写的问题。但对于个人导航页这种单人使用的场景这个劣势完全不是问题。真正要考虑的反而是备份的方便性一个 JSON 文件打包带走复制一份就到新环境了运维成本几乎为零。2.3 全文搜索与快捷键效率提升的两把利器导航页的搜索功能和快捷键是我用下来提升效率最明显的两个设计。搜索功能并不是简单的标题匹配我做了一层模糊匹配和权重排序。搜索结果先按标题匹配度排序标题开头命中的排最前然后是标题包含关键字的结果最后是 URL 地址包含关键字的结果。比如我输入 gh会优先匹配到 GitHub 而不是 GitLab因为 GitHub 的标题前面就是 gh 两个字母这个权重逻辑让搜索结果更符合直觉。快捷键方面我实现了两个最实用的操作。第一个是按 / 直接聚焦到搜索框这个可能是整个导航页利用率最高的快捷键第二个是 Ctrl数字键直接跳到对应分组和浏览器标签页切换的肌肉记忆保持一致上手零成本。还加了一个按 Esc 关闭所有折叠分组的操作算是细微之处的体贴。这里额外说一点快捷键不仅要符合直觉还要注意不要和浏览器原生快捷键冲突。比如 CtrlT 是新开标签页CtrlW 是关闭标签页这些是我不会去碰的保留键位。为了这件事我还专门整理了一张浏览器快捷键对照表把可能冲突的键位剔除了。2.4 图标与品牌识别一套可持续维护的图标管理方案导航页的图标处理也是容易翻车的点。图标做得太重影响加载速度做得太糙影响美观度。我试过几种方案包括外链第三方图标库、把图标打包成雪碧图、用 Font Awesome 字体图标最后定为用 Web 字体加本地 SVG 图标的组合方案。具体实现上对于互联网知名站点我直接用 favicon API 从目标站点实时拉取图标比如 GitHub、Google、Twitter 这些大站都有公开的 favicon 地址。对于小众或内部系统我在 data/assets/favicon 目录下放置手工优化的 SVG 图标通过 JSON 里的 icon 字段指定没有指定时就走默认图标。这套方案的加载速度比全量加载图标库快很多因为图标按需加载、按需缓存不会首屏就拉几个 MB 的字体文件。还有一个细节是图标缓存策略。favicon 虽然是小文件但如果每次打开页面都重新拉一遍几百个链接加起来流量也不少。我在 Nginx 层面对图片资源设置了七天的强缓存同时对 favicon 接口设置了带指纹的 URL 参数目标站点换图标时我可以手动更新参数强制刷新缓存既保证了用户体验又避免了资源浪费。3. 环境准备与部署实操说完设计和思路接下来进入真正动手的环节。所有命令和配置我都尽量给完整你跟着走一遍就能搭起来一个能用的版本。我会假设你已经具备最基本的命令操作基础比如 cd、mkdir、systemctl 这些操作不需要我再解释含义。3.1 服务器配置与基础环境安装我用的是一台 1 核 2G 的入门级云服务器系统是 Ubuntu 22.04这个配置跑导航页加几个轻量服务完全够用。如果你手头没有云服务器用一台不关机的旧电脑装 Ubuntu Server 也行甚至树莓派 4B 都能带得动因为这个应用的资源消耗实在是很低。基础环境的安装分三步走。第一步更新系统包管理器索引和基础软件包sudo apt update sudo apt upgrade -y第二步安装 Docker 和 Docker Compose 插件。这一步在 Ubuntu 上用官方脚本是最省事的curl -fsSL https://get.docker.com | bash -s docker sudo systemctl enable --now docker第三步验证 Docker 是否安装成功sudo docker version sudo docker compose version这两条命令只要有正常输出就说明安装没问题了。需要注意用官方脚本安装的 Docker当前用户默认不在 docker 用户组里直接运行 docker 命令会提示权限不足。我的习惯是把自己的账号加入 docker 组sudo usermod -aG docker $USER执行之后需要退出 SSH 重新登录组权限才能生效。3.2 Nginx 与 Docker Compose 配置编写接下来是核心配置文件的编写。Nginx 在这里承担两个职责作为静态文件服务器提供前端页面以及通过反向代理转发 API 请求和搜索结果请求。我直接把 nginx/conf.d/nav.conf 的关键配置拿出来说明server { listen 80; server_name nav.example.com; root /usr/share/nginx/html; index index.html; # 静态资源缓存策略 location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg)$ { expires 7d; add_header Cache-Control public, no-transform; } # 主页面不缓存保证配置更新后立即可见 location /index.html { add_header Cache-Control no-cache, no-store, must-revalidate; } # API 代理转发 location /api/ { proxy_pass http://nav-backend:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这里有两个细节值得注意。第一个是对 index.html 设置不缓存因为每次修改配置后我都希望刷新浏览器能立刻看到最新版本不让浏览器从缓存里取旧页面。第二个是 API 代理通过 Docker 内置的 DNS 解析服务名 nav-backend 找到后端容器这样做的好处是容器 IP 变化后不需要修改配置文件。然后在项目根目录写 docker-compose.ymlversion: 3.8 services: nav-frontend: image: nginx:1.25-alpine container_name: nav-frontend restart: always ports: - 8080:80 volumes: - ./web:/usr/share/nginx/html:ro - ./nginx/conf.d:/etc/nginx/conf.d:ro depends_on: - nav-backend networks: - nav-network nav-backend: image: node:20-alpine container_name: nav-backend restart: always working_dir: /app volumes: - ./data:/app/data - ./server:/app/server command: sh -c npm install --production node server/app.js environment: - NODE_ENVproduction - PORT8080 networks: - nav-network networks: nav-network: driver: bridge端口映射我特意把前端的 8080 映射到宿主机因为 80 端口通常会被其他服务占用改成 8080 可以避免端口冲突。如果你打算只给自己用前端这层 Nginx 也可以省掉直接暴露后端端口加静态文件托管但多一层 Nginx 的好处是以后想加 HTTPS 证书、加防盗链配置都很方便扩展性更好。3.3 数据准备与后端接口实现部署之前需要先把数据和后端代码准备好。我在 data 目录下创建四个文件links.json 存放链接数据、settings.json 存放站点标题和主题配置初始内容就按前面 JSON 示例的结构先把常用的十几个链接填进去后续再逐步扩充。后端的接口实现其实非常简洁我用 Node.js 写了几行代码就完成了核心功能const express require(express); const fs require(fs); const path require(path); const app express(); const DATA_DIR /app/data; app.use(express.json()); // 获取所有链接数据 app.get(/api/links, (req, res) { const raw fs.readFileSync(path.join(DATA_DIR, links.json), utf-8); res.setHeader(Content-Type, application/json); res.status(200).send(raw); }); // 更新链接数据 app.put(/api/links, (req, res) { const body JSON.stringify(req.body, null, 2); fs.writeFileSync(path.join(DATA_DIR, links.json), body, utf-8); res.status(200).json({ ok: true }); }); // 前端静态资源托管路径 app.use(express.static(/usr/share/nginx/html)); app.listen(8080, () { console.log(nav backend started at port 8080); });这里的接口设计遵循一个原则读接口不设缓存每次请求都返回最新数据写接口做了简单的 JSON 语法校验避免格式错误导致整个文件不可用。考虑到这个后端只有自己在用没有加鉴权但如果你的导航页部署在公网建议至少要挂一层 Basic Auth 或者部署到内网再走内网穿透防止别人乱改你的配置。3.4 六步完成部署全流程配置都准备好了部署过程就是几条命令的事。# 第一步进入项目目录 cd ~/nav # 第二步创建必要的目录结构 mkdir -p web css js data nginx/conf.d server # 第三步把前面准备的 web 页面文件放入 web 目录 # 把 nginx 配置放入 nginx/conf.d 目录 # 把 server/app.js 放入 server 目录 # 把 data/links.json 和 data/settings.json 放入 data 目录 # 第四步构建并启动容器 docker compose up -d --build # 第五步查看容器运行状态 docker compose ps如果一切正常你会看到两个容器显示 running 状态。打开浏览器访问 http://服务器IP:8080就能看到导航页已经跑起来了。第六步是把域名解析到服务器 IP然后在云服务商的安全组里放行 8080 端口。部署过程中遇到端口被占用、配置文件语法错误是家常便饭后面专门有一节讲排错这里先不展开。4. 二次开发与深度优化实践基础版本跑起来之后只是一个能用的程度。真正让它变得好用的是我在后续两个多月里陆陆续续做的几项优化。这些优化从用户体验、加载性能、维护便利性几个角度切入每一项都解决了一个实际痛点。4.1 前端渲染优化从白屏到首屏秒开导航页的首屏加载速度直接决定了用户愿不愿意继续用下去。我的优化思路是前端渲染链路做减法。页面不引用任何重型前端框架只有一个 main.js 文件完整的压缩体积是 11.6KB其中还包含了大段的注释。加载流程也做了精简HTML 里直接内联了页面骨架和样式关键路径让文字和背景色不需要等 CSS 和 JS 加载就能显示。然后通过异步请求获取 links.json 数据拿到之后用原生 DOM 操作把链接列表渲染出来。实测下来在 4G 网络环境下首屏渲染时间稳定在 0.8 秒以内这个速度基本接近静态页面的极限了。这里要强调一个反直觉的结论对于导航页这种小应用引入 Vue 或 React 这类框架并不会带来多少效率提升反而会拖慢首屏加载速度因为框架本身的解析和执行也要消耗时间。原生 JavaScript 配合 DOM 操作是这个场景下的最优解。这个结论不适用于复杂应用单就用导航页这个场景来说越简单越快是不变的真理。4.2 个性化配置主题切换与自定义排序导航页是个人工具个性化配置就显得特别重要。我在 settings.json 里暴露了几个可配置项包括站点标题、主题色、背景图、封面布局模式等。主题切换功能我设计了一套基于 CSS 变量的方案。主题色、背景色、文字颜色都定义成 CSS 变量切换主题时只需要修改 html 元素上的>location /api/ { auth_basic Nav Admin; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://nav-backend:8080/api/; }htpasswd 文件可以用 openssl 命令生成echo admin:$(openssl passwd -apr1 你的密码) nginx/.htpasswd第二件事是配置防火墙只放行需要用到的端口。我的习惯是在防火墙层面只开放 80/443 端口8080 端口不对公网开放而是通过 Nginx 反向代理来访问。这样做的好处是攻击面会小很多。第三件事是启用 fail2ban 做 SSH 暴力破解防护。这个虽然跟导航页本身关系不大但既然服务器暴露在公网基础的安全防护还是应该做全避免服务器失陷之后导航页跟着遭殃。4.4 多端适配手机端与桌面端的体验差异处理手机端适配是我开发后期才认真处理的部分。一开始桌面端调好了就觉得大功告成结果有次在外地用手机打开导航页发现布局完全崩了按钮小得手指都点不准分组折叠功能也失效了体验相当糟糕。后来专门花了一个晚上做响应式改造。核心思路是用 CSS Grid 的自动填充特性代替固定栏数给网格设置一个最小宽度然后让浏览器根据屏幕宽度自动决定排列几列.link-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(160px, 1fr)); gap: 12px; }这个方案的效果是宽屏自动排多列窄屏自动降为两列或一列不需要写一堆媒体查询断点。配合在移动端隐藏大块的背景图、缩小图标尺寸、增大点击热区最终的移动端体验虽然达不到客户端应用的水平但日常临时查个网址、点个链接是完全没问题的。5. 日常维护与数据备份方案导航页不是一个部署完就能一劳永逸放着的项目它需要日常维护和定期备份。这节分享我在维护过程中沉淀下来的流程和工具以及踩过的几次数据丢失的坑。5.1 定时备份防止“一失足成千古恨”导航页最重要的资产是 data 目录下的 links.json 和 settings.json这两个文件记录了所有链接配置和界面设置。如果服务器硬盘故障或者误操作把容器删了没备份就意味着多年积攒的几百个链接一夜清零。我的备份策略分三个层级。第一层是本地定时备份写了一个简单的 cron 任务每天凌晨把 data 目录打包保留最近七天的版本0 2 * * * cd ~/nav tar -czf backup/nav-$(date \%Y\%m\%d).tar.gz data find backup -type f -mtime 7 -delete第二层是异地备份用 rclone 把备份文件同步到对象存储周期是每周一次。第三层是配置审计每当我对 links.json 做重大修改之前都会手动复制一份带日期后缀的版本防止改坏了无法回滚。这里要强调一个血泪教训有次我给导航页加批量导入功能代码里有个 bug 导致前端把整个空数组写回了 links.json等我发现的时候原文件已经被覆盖了。幸好有当天的 tar 备份用一条命令就恢复了。5.2 容器更新与迁移从一台服务器搬到另一台Docker 的好处之一就是迁移方便。有一次我需要把导航页从原来的服务器迁移到新买的一台性能更好的机器上整个过程只花了一刻钟。具体步骤是在旧服务器上打包整个项目目录排除备份文件传到新服务器上然后在新服务器上执行 docker compose down再执行 docker compose up -d。因为数据目录是挂载在宿主机上的容器重建不会影响数据所以迁移过程异常平滑。升级 Nginx 镜像版本也类似先 pull 新镜像再 docker compose up -d 让 Compose 自动重建容器即可。需要注意的点是重建容器前最好先看一下 release notes确认新版本的配置语法没有破坏性变更否则可能出现升级后服务无法启动的尴尬局面。5.3 性能监控与日志轮转导航页虽小运行状态还是要关注的。我加了两个轻量监控手段一个是 Docker 自带的健康检查在 compose 文件里给服务配置 healthcheck另一个是 Nginx 的访问日志分析每周粗略看一下有没有异常请求。日志轮转也需要重视。Nginx 默认会把访问日志无限地写下去时间一长磁盘容易被打满。我在宿主机上配置了 logrotate保留十四天的日志并按天切割多余的历史日志自动清理/var/log/nginx/*.log { daily rotate 14 compress delaycompress missingok notifempty }这套方案几乎不需要额外维护在低流量服务器上可以几个月都不用瞄一眼。导航页的日常运维成本算下来平均每周花不到十分钟主要就是看看有没有链接失效、备份是否正常执行。6. 常见问题与排查技巧实录自建导航页的过程中我遇到了不少问题有一些是网上搜都搜不到解决方案的冷门坑。整理成问答的形式方便你遇到问题时快速对照排查。6.1 问题速查表问题现象可能原因排查方法解决方案容器启动失败配置文件格式错误docker compose config 校验语法根据报错修正 YAML 格式80 端口被占用其他 Web 服务占用了端口ss -lntp 查看端口占用改映射端口为 8080页面样式正常但链接加载不出来后端接口异常或数据文件损坏curl 测试 /api/links 返回结果检查 links.json 格式和路径挂载修改配置后刷新页面不生效浏览器缓存了旧页面打开开发者工具查看 Console 报错强制刷新 CtrlShiftR或调整缓存头手机上字体太大/按钮太小缺少 viewport meta 标签查看 HTML head 区域添加meta nameviewport contentwidthdevice-width, initial-scale1HTTPS 证书续期失败端口未放行或域名解析异常certbot renew --dry-run 测试检查云服务商安全组和 DNS 解析6.2 我在部署时遇到的一个“诡异”问题分享一个我排查了一整天才解决的典型案例。当时导航页在服务器本地访问一切正常但从外网访问时页面能打开API 请求却一直返回 404。前端页面是 Nginx 提供的API 是通过 Nginx 代理到后端容器的404 说明请求根本没到达后端。我先在服务器上直接 curl 后端接口发现返回正常数据然后 curl Nginx 的代理地址发现 404。这就说明问题出在 Nginx 代理配置上。接着查看错误日志多数时候真相就在这里。最终定位到是 host 头的问题。因为导航页配置了域名但安全组和设备策略对外网访问的 Host 头有限制Nginx 的 proxy_set_header Host $host 会把请求原始域名透传给后端之后我在 Nginx 配置里加了一条对来源域名的校验把待部署的正式域名加到了允许列表问题就解决了。这个案例的教训是部署问题排查要逐层定位日志是最好的助手别靠猜。6.3 常见避坑经验总结所有容器配置目录尽量用相对路径挂载不要用绝对路径。相对路径在迁移时不用改配置绝对路径换服务器就得逐个改。接口写操作拖到 Docker 容器时间同步以后再做如果服务器系统时间不对备份和定时任务会全部乱套。对 Web 目录设置只读挂载防止容器内部被写入垃圾文件格式是在冒号后加 ro。链接配置文件改完后先备份再覆盖不要直接在服务器上用 vim 编辑容易碰到编辑器自动生成备份文件导致格式错乱。Docker Compose 配置里的环境变量尽量不要硬编码敏感信息建议使用 .env 文件或者 Docker Secret 管理。7. 效果评估与扩展方向导航页稳定运行一段时间后我做了个小结。核心数据指标首屏加载时间平均 0.8 秒从输入域名到完成一次目标搜索平均耗时大约 3 秒不包括目标网站自身的加载时间日常维护每周不到十分钟。这个效率和直接在浏览器地址栏输入域名相比在访问长网址和不常记的链接时效率提升明显。从使用体验来说家里的长辈用我做的极简版导航页学会把常用的医院挂号、社保查询、新闻网站集中在首页他们觉得比手机里攒一大堆 App 要直观。我自己日常办公场景里把十几个内部系统的入口放到了开发分组配合搜索快捷键基本做到鼠标不离开键盘就能打开任意内部系统。后续可以扩展的方向我大概列了几个备选第一加入健康检查功能定时探测链接是否失效失效的自动标记出来方便清理第二做一个简单的访问统计看看哪些分组、哪些链接使用频率最高帮助调整布局优先级第三研究一下如何让导航页变成一个统一入口把常用工具的搜索框集成进去比如输入关键词直接搜维基百科、GitHub 或地图这样能进一步减少操作步骤。这几个方向里第二和第三个我都已经完成了初步版本。访问统计的埋点很简单前端点击时发一个请求到统计接口后端把数据追加到一个 JSON 文件就行聚合展示我也做了一个简单的时间戳统计页面。统一搜索框集成做出来后我把常用的搜索引擎、代码搜索、知识库都加了进去支持一类网址前缀识别比如输入 py 然后接上关键词会自动跳转到 Python 官方文档搜索效率提升相当明显。整体做下来我的体会是导航页虽然技术含量不高但特别考验需求分析和细节打磨的能力。一开始觉得“不就是把链接列出来吗”真正做起来才发现分类怎么分、排序怎么排、搜索怎么匹配、手机端怎么适配、备份怎么做每一项都值得认真对待。尤其当你用上一个自己配置的导航页那种顺手和贴合是任何现成产品都给不了的。如果你也一直想搭一个自己的导航页不妨照着这篇内容先跑起来一个版本再根据自己的使用习惯慢慢调相信最终的结果会让你满意的。
