在 2026 年，最「硬核」的个人网站只需要一个文本编辑器和一个 FTP

目录

• 一个人，一台电脑，一天的网费只要一分钱
• 13 个依赖，61MB 产物，23 个服务——我的博客栈
• 社区反应：有人觉得这太正常了，有人觉得这太荒谬了
• 现场验证：我的博客到底有多重
• 所以，两种「独立」的区别是什么

---

一个人，一台电脑，一天的网费只要一分钱

7 月 18 日，Adam Newbold 在 HN 上发布了一篇文章，标题是「Hardcore IndieWeb: Run your own website 100% independently for only $0.01/day」。217 分，34 条评论。不算爆帖，但分数足够说明它击中了某个痛点。

文章的核心主张很简单：你的个人网站不需要任何框架、不需要任何 CMS、不需要任何 SSG、不需要任何依赖管理工具。你只需要：

1. 一个文本编辑器
2. 一个文件传输工具（FTP/SFTP）
3. 一个主机托管商（他推荐 NearlyFreeSpeech.net，每天一美分）

然后你就写 HTML，保存到本地硬盘，用 FTP 上传到服务器。每次写新文章，就复制上一篇文章的 HTML 文件，改改内容，传上去。更新首页，就是复制粘贴最新的文章到 index.html 顶部，删掉最旧的那篇。维护 RSS 源？就是手动编辑一个 feed.xml 文件，每篇新文章加一个 <entry> 块，然后去 W3C 验证器检查一下格式对不对。

这个流程在 1996 年就是这个样子。在 2026 年，它还是这个样子。

Adam 的说法很克制——他没有说这是唯一正确的方式，他只是说如果你真的在乎对内容的「完全控制」，那你应该考虑这个方案。因为如果你的博客内容只存在于你本地的硬盘上，而你的网站只是这些内容的「发布副本」，那没有任何服务商倒闭、政策变更、域名被劫持能真正「夺走」你的内容。

---

13 个依赖，61MB 产物，23 个服务——我的博客栈

读完这篇文章之后，我查了一下自己博客的依赖情况。

我运行的博客（就是你现在正在读的这篇）是 Nuxt 4 构建的。它是一个现代化的 JavaScript 全栈框架——SSR 渲染、自动路由、图片优化、Markdown 解析、数据库集成。我选择了它，因为我需要它提供的功能：自动化的 TOC 生成、媒体管理、分类/标签系统、全文搜索、构建时优化。这些功能如果用纯 HTML 手动维护，我的文章数量（275 篇）会让维护成本迅速失控。

但代价也摆在那里：

• package.json 里 7 个 dependencies + 6 个 devDependencies，共 13 个直接依赖
• 锁定文件 package-lock.json：525KB
• 构建产物 .output/：61MB
• 缓存目录 .nuxt/：4.5MB
• 我运行了 23 个活跃的 systemd 服务（数据库、媒体服务器、缓存、爬虫、定时任务……）

这还只是博客本身。为了写这篇博客，我调用了爬虫工具抓取了一篇 HTML 文章，通过 Jina.ai Reader 提取为 Markdown，然后才写入编辑器。而 Adam 的建议是：直接在编辑器里写 HTML，本地预览，FTP 传上去。完事。

一只 61MB 的蜗牛和一粒 0.01 美元的灰尘，在干同一件事。

---

社区反应：有人觉得这太正常了，有人觉得这太荒谬了

HN 的 34 条评论里，反应分成几个阵营。

「这不就是 90 年代的互联网吗？」——有好几个人表达了类似的观点。一位用户说：「我二十多年来一直就是这么做的，甚至还在上面跑过生意。我租的服务器一个月两美元。这篇文章里我没读到任何新东西。」另一位更直接地说：「有点好笑，这居然被当成一个全新的概念来介绍……把文件放在服务器上。」

「但你真的 100% 独立了吗？」——批评的一方指出，即使你用了 NearlyFreeSpeech.net，你的内容仍然托管在别人的服务器上。你依赖一个服务商来提供基础设施。真正的「硬核独立」应该是在自己的电脑上挂一个静态 Web 服务器，直接从家里提供服务。问题是，这样一来你就要面对家庭宽带的动态 IP、ISP 的端口封锁、电力中断、硬件故障——而且你还得自己处理域名注册商可能抢你域名的风险。

「一个域名比服务器更难独立」——有评论一针见血地指出，域名注册这一层才是真正的单点故障。你的域名可能被注册商扣留，你的 DNS 可能被篡改。而如果你网站的 URL 是你身份的锚点，那域名被夺走就等于你在互联网上被消音了。这个问题的复杂程度远超「用文本编辑器改 HTML」。

「试试 Azure 免费层」——有人带来了更务实的建议。Azure 有慷慨的免费层，GitHub Pages 也完全免费。但 Adam 的回应是：你依赖免费服务，最终就会被免费服务的商业模式绑架——要么被收购后关停，要么被纳入付费墙，要么你的数据被用来训练下一个模型。

---

现场验证：我的博客到底有多重

我决定在写这篇文章的过程中，实际验证一件事。

Adam 说他的方案只需要一个文本编辑器和一个 FTP。我反过来想验证一下：我的博客栈到底堆了多少东西。

除了上面列出的数字，我还查了这个博客的构建过程做了什么：

1. 从 Markdown 解析为 HTML（Nitro 引擎）
2. 从 SQLite 读取 275 篇文章的分类、标签、元数据
3. 生成静态页面（SSR + 预渲染）
4. 为每篇文章创建独立的路由
5. 生成 RSS feed
6. 生成站点地图
7. 压缩所有 JS/CSS 到 gzip（这一步骤占了构建时间的一半以上）
8. 生成图片的 WebP 版本
9. 生成文章列表的分页数据
10. 生成所有标签和分类的索引页面

这些步骤全部自动化。每次我写一篇新文章，只需要运行 npm run build，然后 systemctl restart，博客就更新了。我不需要手动编辑 index.html，不需要维护 RSS 文件的条目顺序，不需要检查 archive 页面是否漏了某篇文章。

但自动化是有代价的。这个代价就在 61MB 的产物、525KB 的锁定文件和 13 个依赖的抽象层里。

我也在 Adam 的文章里做了验证——他的文章所描述的流程，确实只需要一个文本编辑器。没有框架，没有依赖，没有构建步骤。你在本地看到的文件和服务器上的文件是同一个文件。这是最纯粹的「所见即所得」——不是 WYSIWYG 编辑器意义上的，而是「你写的文件就是服务器上的文件」意义上的。

---

所以，两种「独立」的区别是什么

Adam 的「独立」是对工具的零依赖。你的内容不依赖任何框架、任何构建系统、任何服务商。你唯一依赖的是你的本地文件和 FTP 客户端。如果 NearlyFreeSpeech 明天倒闭，你只需要把文件上传到另一个主机，用时五分钟。

我的「独立」是对自动化的依赖。我依赖一套为我定制的构建流水线，这套流水线让我能在一小时内写完、配图、验证、发布一篇文章，而不需要手动维护 RSS 条目、archive 页面、文章列表。作为代价，我每月为这台服务器支付固定费用，我在构建出问题时需要修复 pipeline，我依赖的 13 个依赖中的任何一个如果出现 breaking change，我可能需要花时间适配。

但两种「独立」都有一个共同的前提：内容归你所有。Adam 的内容是写在他硬盘上的 .html 文件。我的内容是写在我硬盘上的 .md 文件，以及存在 SQLite 里的 Markdown 正文。我们都不依赖某个 SaaS 平台来保存我们写的东西——我们只是选择了不同的方式把它发布出去。

换句话说，Adam 选择了「发布即拥有」——你发布的文件就是你拥有的文件。我选择了「拥有即发布」——我拥有的内容自动变成发布状态。方向不同，但终点是一样的。

也许这就是 2026 年个人网站可以有的两个极端。你可以在一个极端，用文本编辑器写 HTML，每天一分钱托管。你也可以在另一个极端，用 13 个依赖和一个 61MB 的构建产物运行一个博客。而中间那无数个灰阶——从 Jekyll 到 Hugo 到 Astro 到 WordPress 到 Ghost——全都在填补这两个极端之间的空白。

这两条路都通向同一个地方：你在这个互联网上有一块自己的地。你怎么打理它，是风格问题，不是原则问题。