每当我告诉别人我的博客和工具站是纯静态 HTML 写的，没有任何框架，对方的反应通常是先愣一下，然后问："为什么不用 Next.js？"
这个问题我回答过至少五十次。每次回答，都会引发更深一层的讨论。因为这不是一个技术问题，而是一个决策思维的问题。
在 2026 年，用纯静态 HTML 写网站，听起来就像在汽车时代骑自行车。但当你真正理解了"骑自行车"在什么场景下是最优解，你就会发现：选技术的依据不是"它有多流行"，而是"它解决了什么问题，带来了什么成本"。
纯静态的四个优势
极简部署
我的博客部署在 GitHub Pages 上。一个 HTML 文件，一个 CSS 文件，几个 JS 文件。不需要构建步骤，不需要环境变量，不需要 Docker 容器，不需要 CI/CD 流水线。我写完一篇文章，保存文件，推送到 GitHub，十秒内上线。
有人会说："Next.js 也能导出静态文件啊。"没错，但 Next.js 的静态导出需要一次构建。你改了文章标题，需要重新构建。你升级了依赖，需要重新构建。构建过程可能因为 Node 版本不兼容而失败，可能因为某个依赖的 breaking change 而报错。而纯 HTML——它就是它。你不需要任何东西来"编译"它，因为浏览器本身就是它的运行时。
零运维
我不用操心服务器。不用操心进程是否还活着，内存是否够用，负载是否过高。我的网站就是一堆文件，静静地躺在 GitHub 的服务器上，等着被访问。没有数据库连接池，没有 API 路由超时，没有中间件报错。它永远不会"宕机"，因为静态文件不存在"宕机"这个状态。
对于我一个人维护的工具站来说，这就是理想状态。我的精力应该花在"做什么工具"上，而不是"怎么保证网站不挂"。
长寿命
我写过一篇文章，2009 年，距今已经 17 年了。它现在还能正常打开，没有任何问题。我怀疑如果我用当时流行的框架来写，它可能早就打不开了——框架早已停止维护，依赖早已不兼容，构建工具链早已改变。
HTML 是互联网上最稳定的标准。它不会因为框架的兴衰而失效，不会因为 npm 包的更新而崩溃。我可以把文章存到 U 盘里，十年后插到任何一台电脑上，双击打开，它就能正常显示。
这种"长寿命"对我来说很重要，因为我的博客和工具站不是一个"短期项目"——它们是我打算维护十几年的东西。一个框架的寿命是 3-5 年，但 HTML 的寿命，是互联网的寿命。
低成本
GitHub Pages 免费。Cloudflare 免费。不需要服务器，不需要数据库，不需要 CDN 额外配置。我的博客和工具站，每个月的运营成本是零。
这不是说我"抠门"，而是零成本意味着零压力。我不会因为"这个月服务器费用有点高"而焦虑，不会因为"用户量涨了得升级服务器"而犹豫。成本为零，你就可以专注于内容本身，而不被"运营"分散精力。
为什么不选 Next.js？
我并不是说 Next.js 不好。Next.js 是一个优秀的框架，在正确的场景下它是极其强大的工具。但对我而言，它的优势在我的场景下不存在，而它的成本却真实存在：
我不需要 SSR
服务端渲染的核心价值是什么？SEO 和首屏速度。但我的博客和工具站，内容是纯静态的——一篇文章写完就不会变，一个工具上线后功能就稳定了。静态 HTML 直接由浏览器渲染，不需要 Node.js 服务器来"预渲染"——因为它根本不需要渲染，HTML 就是最终结果。而且，搜索引擎完全能解析静态 HTML，不需要 SSR 来"帮助 SEO"。
我不需要动态路由
Next.js 的基于文件系统的路由很好用，但我的博客只有几十个页面，每个页面都是独立的手写 HTML。我不需要"动态生成"任何页面，不需要"产品详情页"、不需要"用户设置页"。一个页面就是一个文件，一篇文章就是一个 HTML。这种"粗暴"的方式，在页面数量少的时候，反而是最高效的。
团队规模 = 1
框架最大的价值之一是统一团队的开发范式。当你有 5 个、10 个、50 个开发者时，你需要约定文件结构、代码风格、状态管理方式。框架帮你做这些约定。
但我的团队只有我一个人。我不需要约定，我只需要"我能理解"。而纯 HTML ——没有 JSX 语法糖，没有 Hook 规则，没有组件生命周期——对"一个人"来说，理解成本是最低的。
维护成本是首要考量
这是最重要的一点。每当我评估一个技术选型，我首先算的不是"开发效率"，而是"维护成本"。Next.js 每年发布几个大版本，每个版本都有 breaking changes。你升级了 Next.js，可能 React 也要升级，可能某个插件不兼容了，可能构建配置变了。这些"维护"对一个大团队来说可能不算什么，但对一个人来说，每一次维护都是在消耗"做工具"的时间。
我选择纯静态 HTML，不是因为"我不懂框架"，而是因为"我太清楚框架的维护成本了"。
什么情况下我会选框架？
如果我的场景变了，我会毫不犹豫地选框架。比如，如果我的工具站需要用户登录、需要保存用户数据、需要实时协作——那纯静态 HTML 就不够了，我会选一个能处理这些复杂性的框架。
但关键是：不是所有项目都需要框架。很多项目的复杂性，是被框架"创造"出来的，而不是被业务"要求"的。你为了"以后可能需要"而引入了一个框架，然后这个框架带来了构建工具、依赖管理、版本兼容、类型系统……这些"额外"的东西，最后反而成了你最大的负担。
写在最后
技术选型的本质，不是"哪个技术更好"，而是"哪个技术的成本结构更适合我的场景"。Next.js 是一个好技术，但在我"一个人、纯内容、长期维护"的场景下，纯静态 HTML 的成本结构是最优的。
下次你做技术选型的时候，试着把"这个技术流行吗"换成"这个技术对我有什么成本"。你会发现，答案会变得清晰得多。