从Next.js迁移到原生JS：一个日活200+项目的极简架构实践

一、背景

去年年底，我启动了一个小项目——一个每天只更新一道英文猜词游戏的网站。

产品逻辑很简单：每天一道题，6次机会猜一个单词，猜不出来明天再来。无需注册，没有广告，打开即玩。

项目上线三个月，日活稳定在200左右，全部来自自然搜索和社区口碑。

这篇文章不聊产品本身，重点分享一下技术架构的演变过程——从“重型框架”到“极简方案”的迁移，以及在这个过程中学到的一些经验。

二、第一版：重型架构的尝试

项目最开始，我理所当然地选择了当下最流行的技术栈：

• Next.js + Tailwind CSS + Prisma + PostgreSQL

理由是：“正规项目就该用正规架构”“后面扩展起来方便”“大厂都在用”。

结果呢？光是环境配置就折腾了一周。Prisma 的 schema 设计改了又改，Tailwind 的配置调了又调，Next.js 的 App Router 还在坑里没爬出来。

一行业务代码没写。

我开始反思一个问题：对于一个每天只更新一道题、没有用户系统、没有实时交互的网站，我真的需要这些东西吗？

答案是：不需要。

三、第二版：极简方案的重构

想清楚之后，我做了个决定：推倒重来，用最土的方式先把东西跑起来。

最终的技术栈变成了这样：

层级	技术选型	理由
前端	HTML + CSS + Vanilla JS	无需构建工具，直接写直接跑
后端	Node.js (Express)	轻量、熟悉、够用
数据存储	JSON 文件	每天只更新一道题，不需要数据库
用户状态	localStorage	无需服务端存储，零成本

整个项目从重构到上线，只用了三天。

一点感悟：架构设计的核心不是“用多先进的技术”，而是“用多合适的技术”。对于处于验证阶段的产品，过度工程化是比技术债务更危险的陷阱。

四、核心设计：无数据库方案可行吗？

很多人可能会问：不用数据库，用 JSON 文件，靠谱吗？

我的答案是：对于这个场景，完全够用。

数据结构非常简单：

{
  "date": "2026-06-16",
  "answer": "bridge",
  "clue": "A structure that spans a river (6)",
  "hintLevel": 2,
  "videoUrl": "https://..."
}

API 只有两个端点：

• GET /api/puzzle/today —— 返回当天的谜题（不含答案）
• POST /api/puzzle/check —— 校验用户答案

每天的谜题数据在服务器启动时加载进内存，全天提供服务。没有数据库连接池，没有 ORM，没有迁移脚本。

运维也极其简单：

• 部署：git pull && pm2 restart
• 故障恢复：无状态设计，重启即恢复
• 服务器成本：单台低配云服务器，月成本可忽略不计

一点感悟：技术的选择要服务于产品的阶段。在验证阶段，速度比扩展性重要，简单比复杂重要。

五、踩坑记录：教育成本的教训

技术上说完了，顺便分享一个产品层面的坑——虽然跟技术无关，但对做产品的开发者可能有参考价值。

早期版本上线后，我发现一个问题：很多用户来了就走了。

后来才意识到，这个游戏品类（Cryptic Crossword）本身有学习门槛——新手根本看不懂题目在说什么。

解决方案很朴素：每道题配一条几十秒的短视频，讲解这道题的逻辑。

就这么一个小改动，次日留存从20%涨到了45%。

一点感悟：如果你的产品有学习门槛，别指望用户自己看文档。一条几十秒的视频，比什么技术文档都管用。

六、总结

复盘这个项目，有三点体会想分享给正在做独立项目的开发者：

1. 先跑起来，再谈优化。在验证阶段，速度比架构重要。用最顺手的技术把产品推到用户面前，比花一个月搭“完美架构”更有价值。

2. 技术选型要匹配业务阶段。不是每个项目都需要微服务、需要数据库、需要前后端分离。“够用”比“先进”更重要。

3. 用户教育是产品的一部分。如果你的产品有门槛，想办法降低它——视频、引导、示例，什么都行。用户看不懂，再好的技术也白搭。

---

关于作者

独立开发者，关注极简产品设计与技术实践。
个人项目：Minute Cryptic —— 一个每日更新的英文猜词游戏