你有没有想过一个完全免费、无需服务器、还能自定义域名和密码的私人导航站到底是怎么实现的过去搭建一个网站从买服务器、配置环境、部署代码到维护更新每一步都伴随着成本和技术门槛。但现在借助 Cloudflare 的 Pages 和 Workers 等免费服务这一切变得出奇地简单。CF-Navs 这个项目就是这种“零成本建站”思路的一个典型代表。它不是一个复杂的 CMS 系统而是一个轻量、快速、专注于链接管理的导航页生成器。很多人第一眼看到“零成本”和“带密码保护、数据统计”时可能会觉得这要么是噱头要么功能极其简陋。但实际体验下来你会发现它的核心价值恰恰在于它用最少的配置把“拥有一个可定制、有基础防护、能看数据且永不掉线”的私人导航站”这件事变成了一个半小时内就能完成的标准化流程。这篇文章我不会只告诉你“点击这里复制那里”的步骤。我想和你深入聊聊为什么 Cloudflare 这套免费套餐能支撑起一个可用的站点CF-Navs 的设计取舍在哪里密码保护和数据统计这些“高级”功能在免费环境下是如何“曲线救国”实现的以及最重要的——当你真正把它用起来之后如何从“一次部署成功”走向“长期稳定使用”。1. 为什么是 Cloudflare CF-Navs重新理解“零成本”与“可用性”在深入动手之前我们需要先建立一个关键认知这里的“零成本”指的是什么以及它的边界在哪里。1.1 Cloudflare 的免费套餐不只是 CDNCloudflare 早已不是单纯的 CDN 服务商。它的免费套餐是一个功能丰富的开发者平台套件这正是 CF-Navs 这类项目得以存在的基础。核心组件包括Cloudflare Pages:用于托管静态网站。它提供全球分发、自动构建从 Git 仓库拉取代码并构建、自定义域名和免费的 SSL 证书。对于 CF-Navs 这种基于 Vue.js 等框架构建的静态应用Pages 是完美的归宿。你不需要关心服务器运维。Cloudflare Workers:一个无服务器函数Serverless Functions平台。免费套餐有每天 10 万次的请求额度。CF-Navs 利用 Workers 来实现密码保护和访问数据统计这两个需要“后端逻辑”的功能。这是实现“静态站点动态能力”的关键。Cloudflare KV:一个键值对存储数据库。免费套餐有 1GB 的存储和每天 1000 次写入操作。CF-Navs 用它来存储经过哈希加密的密码和简单的访问计数数据。Cloudflare DNS:免费的域名解析服务。你可以将你自己的域名比如nav.yourname.com指向 Pages 或 Workers。把这些服务组合起来就构成了一个完整的、具备基础后端能力的应用托管环境。“零成本”的真实含义是在 Cloudflare 设定的免费额度内对于个人导航站这种低频访问场景几乎不可能用完你无需支付任何费用。成本从金钱转移到了“理解并配置这些服务”的学习成本上。1.2 CF-Navs 的定位专注的链接管理工具CF-Navs 没有试图做一个全功能的书签管理器或复杂的门户。它聚焦于一个核心场景为你个人或小团队快速生成一个美观、分类清晰、可搜索的网页导航首页。它的设计体现了明显的取舍舍复杂的用户系统、多级权限、富文本编辑、第三方插件生态。取极简的配置一个 JSON/YAML 文件定义所有链接、响应式设计、暗色/亮色主题、内置搜索、基于分类的卡片式布局。这种取舍使得它代码结构清晰构建后的静态文件很小非常适合部署在 Pages 上加载速度极快。它的“可定制性”体现在前端样式和链接数据上而不是系统功能上。理解这一点你就能明白它适合谁不适合谁。适合谁开发者、技术爱好者、需要统一入口的小团队、希望有一个比浏览器书签更美观易用的个人主页的用户。不适合谁需要复杂权限管理、希望有社交功能、需要频繁由非技术人员更新内容的大型组织。2. 从零开始部署流程与核心配置详解让我们把概念落地。整个部署过程可以概括为“准备数据 - 托管前端 - 配置后端保护”。下面是一个详细的、可操作的路径。2.1 前期准备三样必不可少的东西在点击任何部署按钮之前请确保你手头有这三样一个 Cloudflare 账户。这是毫无疑问的前提。一个 GitHub 或 GitLab 账户。CF-Navs 的代码托管于此并且 Cloudflare Pages 需要连接你的 Git 仓库来自动构建。可选但推荐一个自定义域名。你可以使用 Cloudflare Pages 提供的*.pages.dev子域名但拥有一个自己的域名如nav.yourname.com会让你的导航站更正式、更容易记忆。域名可以在任意注册商购买然后将其 DNS 解析转移到 Cloudflare 管理这是免费的。2.2 第一步Fork 并配置你的导航站数据CF-Navs 的项目代码通常托管在 GitHub 上。你的第一步不是直接部署而是“复制”一份代码到自己的仓库并修改成你自己的内容。Fork 项目访问 CF-Navs 的 GitHub 仓库点击右上角的Fork按钮。这会在你的 GitHub 账户下创建一个完全独立的副本。修改导航数据在你的 Fork 出来的仓库里找到定义网站链接的核心配置文件。根据项目不同它可能是src/data/links.json、config.yml或类似的文件。这个文件的结构通常如下[ { category: 开发工具, items: [ { name: GitHub, url: https://github.com, icon: github, description: 代码托管平台 }, { name: Vercel, url: https://vercel.com, icon: globe, description: 前端部署平台 } ] }, { category: 日常, items: [ { name: Gmail, url: https://mail.google.com, icon: mail, description: 电子邮件 } ] } ]你需要按照这个格式将category、name、url、icon通常项目会提供一套图标集名称和description替换成你自己的常用网站。这是整个部署过程中最体现个性化的一步。可选修改基础配置查看项目根目录的配置文件如vite.config.js、vue.config.js或config.js你可能需要修改站点标题title、描述description等元信息。有些项目也在这里设置主题色。2.3 第二步使用 Cloudflare Pages 部署前端配置好数据后就可以让网站“活”起来了。登录 Cloudflare Dashboard在侧边栏找到“Workers Pages”。点击“Create application”-“Pages”-“Connect to Git”。授权 Cloudflare 访问你的 GitHub 账户并选择你刚刚 Fork 的 CF-Navs 仓库。配置构建设置这是关键一步。系统通常会自动检测项目类型如 Vue.js、React。你需要确保Build command:通常是npm run build或yarn build。Build output directory:通常是dist或build。你必须确认项目构建后生成的静态文件目录名填错会导致部署后是空白页。Root directory:一般保持默认/。点击“Save and Deploy”。Cloudflare Pages 会自动拉取代码、安装依赖、执行构建命令并将生成的静态文件部署到全球网络。几分钟后你会获得一个*.pages.dev的临时域名访问它应该能看到你刚刚修改过的导航站了。至此一个无密码保护、无数据统计的纯静态导航站已经部署完成。它已经具备了核心功能。2.4 第三步实现密码保护与数据统计核心进阶现在我们来添加“高级”功能。这需要用到 Cloudflare Workers 和 KV。2.4.1 创建并绑定 KV 命名空间KV 是用来存密码哈希值和计数的地方。在 “Workers Pages” 页面切换到“KV”标签页。点击“Create namespace”给它起个名字比如CF_NAVS_STORE。创建成功后记住其“Namespace ID”。回到你的 Pages 项目设置中找到“Settings”-“Functions”-“KV namespace bindings”。点击“Add binding”。Variable name:填写一个在 Worker 代码中使用的变量名例如MY_KV。这个名称后面在 Worker 代码里要严格对应。KV namespace:选择你刚刚创建的CF_NAVS_STORE。保存设置。2.4.2 部署密码保护 WorkerCF-Navs 项目通常会提供一个现成的 Worker 脚本通常是一个.js文件比如_worker.js或auth-worker.js。如果没有你需要根据其文档编写一个简单的 Worker逻辑是拦截对 Pages 站点的所有请求。检查请求的 Cookie 或 URL 中是否有有效的认证令牌。如果没有则返回一个输入密码的 HTML 页面。用户提交密码后Worker 将密码与 KV 中存储的哈希值进行比对使用如bcrypt的算法但 Worker 环境可能使用 Web Crypto API。验证通过后设置一个加密的 Cookie 并重定向到原始请求。在第一次设置时需要一个单独的路径如/set-password来初始化 KV 中的密码哈希。部署 Worker 有两种常见方式方式A与 Pages 集成。将 Worker 脚本文件如_worker.js放在你 Git 仓库的根目录。Cloudflare Pages 在部署时会自动识别并将其作为整个站点的“Functions”运行。这是最简洁的方式。方式B独立部署。在 “Workers Pages” 页面创建一个独立的 Worker将脚本粘贴进去然后通过 Workers 的“Routes”功能将你的导航站域名如nav.yourname.com/*的流量指向这个 Worker。这个 Worker 再代理请求到你的 Pages 站点。初始化密码按照项目文档说明首次部署后访问一个特定的初始化端点如https://your-site.pages.dev/set-password?secretYOUR_SETUP_KEY设置你的初始密码。这个密码的哈希值会被存入 KV。之后请务必禁用或删除这个初始化端点以免被他人利用。2.4.3 实现基础数据统计统计功能同样依靠 Worker 和 KV。在 Worker 脚本中在处理每个经过认证的页面请求时或针对特定 API 端点可以执行一个简单的计数操作。使用 KV 的get和put方法。例如// 伪代码示例 export default { async fetch(request, env) { // ... 密码验证逻辑 ... // 计数逻辑 let count await env.MY_KV.get(page_views); count parseInt(count || 0) 1; await env.MY_KV.put(page_views, count.toString()); // ... 继续返回页面 ... } }然后你可以再创建一个简单的 API 端点如/api/stats从 KV 中读取page_views并返回 JSON 数据。最后在导航站的前端页面中通过 JavaScript 调用这个 API 来展示统计数据。请注意Cloudflare KV 的免费套餐有写入次数限制且不是实时强一致性的数据库。因此这种统计方式不适合高并发、精准计数的场景但对于个人导航站查看大致访问趋势是完全足够的。这是一种典型的在免费架构下实现的“够用”方案。3. 关键配置解析与避坑指南部署流程走通只是开始。要让站点稳定、安全、符合预期你需要理解以下几个关键点。3.1 自定义域名与 HTTPS添加自定义域名在 Pages 项目的“Settings”-“Custom domains”中点击 “Add custom domain”输入你的域名如nav.yourname.com。DNS 配置Cloudflare 会自动提示你需要添加的 CNAME 记录通常是将navCNAME 指向你的项目.pages.dev。确保你的域名 DNS 由 Cloudflare 管理这些记录会自动添加。SSL/TLS在 Cloudflare 的“SSL/TLS”设置中确保模式为“Full (strict)”。Cloudflare 会自动为你颁发并管理 SSL 证书实现全站 HTTPS。这是免费的且必须开启。3.2 密码安全这不是铜墙铁壁但足够防君子基于 Worker 和 KV 的密码保护有其特点优点实现简单无需独立后端服务器成本为零。局限性密码验证逻辑运行在边缘虽然安全但密钥和哈希值存储在 KV 中。认证状态依赖于 Cookie如果用户清除 Cookie 则需要重新登录。它不能防止直接访问背后的 Pages 原始*.pages.dev域名如果该域名被泄露。因此最佳实践是启用自定义域名并禁用或隐藏原始的.pages.dev域名。安全建议使用强密码。定期或在怀疑泄露时通过初始化流程重置密码。确保初始化端点仅在首次设置时使用之后无法被公开访问。3.3 数据备份你的配置才是核心资产在这个架构下Cloudflare Pages 托管的是构建后的静态文件Worker 脚本在你的 Git 仓库里而导航数据links.json也在 Git 仓库里。KV 中只存储密码哈希和访问计数。因此备份的核心就是备份你的 Git 仓库。你所有的定制内容链接、图标、描述、样式配置都安全地保存在那里。如果 Cloudflare 服务出现问题概率极低你随时可以用同样的代码和配置在 Vercel、Netlify 或其他支持静态托管的服务上重新部署。你可以定期将你的 Git 仓库克隆到本地或者推送到另一个远程仓库如 GitLab作为异地备份。3.4 常见问题排查部署后显示空白页首要检查构建输出目录。99%的问题出在这里。确认dist或build目录下是否有index.html。查看 Pages 部署日志“Deployments” - 点击某次部署 - “View build logs”看构建过程是否有错误。检查浏览器控制台F12是否有 JavaScript 报错。密码保护无效可以直接访问检查 Worker 脚本是否部署成功。访问your-domain.com/_worker.js如果存在看是否能被访问通常会被 Worker 本身拦截。检查 KV 绑定是否正确Worker 代码中使用的变量名如env.MY_KV是否与 Pages 设置中的 “Variable name” 完全一致大小写敏感。清除浏览器 Cookie 重新测试。数据统计不更新KV 有轻微的数据传播延迟最终一致性可能不是实时更新。检查 Worker 代码中的计数逻辑是否被正确触发是否在认证通过后才计数。检查 KV 的写入额度是否超限免费套餐每日 1000 次写入对于个人站几乎不可能。4. 超越部署将一次性项目融入你的工作流成功部署并配置好 CF-Navs故事才刚刚开始。它的长期价值在于如何成为你数字生活的一个稳定节点。4.1 内容维护让更新变得简单每次要加一个新网站难道都要去改代码、提交、等构建吗其实有更优雅的方式将数据文件外部化你可以改造项目将links.json存放在一个更容易更新的地方例如项目内的一个.md文件用更简单的格式书写。一个独立的、公开的 Gist 或 JSON 文件 URL。站点运行时通过fetch加载这个 URL。这样你更新 Gist导航站内容就自动更新了可能需要配合简单的缓存策略。建立更新习惯即使直接改 JSON 文件你也可以在本地用 VS Code 等编辑器打开修改后git commit push。Cloudflare Pages 会自动触发新的构建和部署通常在1-2分钟内完成。把这变成一种每月一次的整理习惯。4.2 功能扩展在边界内探索免费套餐有其限制但仍有扩展空间更丰富的统计除了 PV你可以利用 Worker 记录更细粒度的信息如访问时间、分类点击次数需前端配合发送事件然后定期将 KV 数据导出分析或发送到更专业的分析平台如 Google Analytics但需注意其脚本对速度的影响。多主题与样式微调深入研究项目的样式文件通常是src/styles或tailwind.config.js你可以自定义颜色、间距、圆角等打造独一无二的视觉风格。集成小工具在页面侧边栏或底部添加一些实用小组件如搜索框调用 DuckDuckGo/Bing API、天气调用免费 API、便签利用浏览器 LocalStorage等。这需要对前端代码进行修改。4.3 架构思考从 CF-Navs 到“零成本应用”模式CF-Navs 的架构模式具有启发性。它清晰地演示了如何利用现代云服务的免费层将传统需要服务器的工作拆解静态内容 - Cloudflare Pages (全球托管)动态逻辑/API - Cloudflare Workers (边缘计算)小块持久化数据 - Cloudflare KV (边缘存储)用户身份 - 简单的 Cookie 密码哈希这个模式可以复用到很多其他轻量级应用场景一个简单的待办事项列表、一个投票工具、一个只读的信息展示板、一个联系表单收集器等等。你学到的不只是部署一个导航站而是一种构建和部署无服务器微应用的方法论。最终CF-Navs 提供的不仅是一个浏览器首页。它提供了一个完全由你控制、设计、维护的数字空间入口。当你在地址栏输入那个熟悉的域名按下回车看到完全按自己心意排列的、快速加载的站点集合时那种效率和掌控感是使用任何第三方导航网站都无法替代的。而这一切的起点不过是理解了几个免费服务的组合方式并愿意花一点时间动手配置。