我的极简架构实践：如何用 JSON 文件支撑一个日活 200+ 的 Web 应用

一、 项目背景与面临的挑战

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

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

项目上线三个月后，日活稳定在 200 左右，全部来自自然搜索和社区口碑。这篇文章不聊产品运营，重点分享一下技术架构的演变过程——从“重型框架”到“极简方案”的迁移，以及在这个过程中学到的一些经验。

二、 第一次尝试：陷入“重型架构”的陷阱

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

• Next.js + Tailwind CSS + Prisma + PostgreSQL

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

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

一行业务代码都没写。

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

答案很明确：不需要。

三、 第二次尝试：极简方案的重构

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

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

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

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

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

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

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

数据结构非常简单：

json

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

API 只有两个端点：

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

运维也极其简单：

• 部署：git pull && pm2 restart

• 故障恢复：无状态设计，重启即恢复

• 服务器成本：单台低配云服务器即可支撑

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

五、 踩坑记录：技术之外的教训

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

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

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

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

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

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

六、 总结：三点经验

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

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

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

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

---

关于作者

独立开发者，关注极简产品设计与技术实践。成果体验地址 minutecryptic

本作品采用《CC 协议》，转载必须注明作者和本文链接