「 简记往来」第三篇：技术选型——为什么选了微信小程序+Node.js？
·
一、技术选型的三层决策
做简记往来之前，我面临三个层面的技术选型：
- 前端形态：小程序 vs App vs H5？
- 后端框架：Node.js vs Java vs Go？
- 数据库：MongoDB vs MySQL vs 其他？
每一层都有多个选项，而且每个选项都有各自的“支持者”。
我不追求“最好”的技术，只追求“最适合”的技术。下面把我的完整思考过程写出来。
二、前端形态：为什么选小程序？
| 方案 | 优点 | 缺点 | 是否适合 |
|---|---|---|---|
| 原生App | 体验最好、功能最强 | 开发成本高、需要下载安装 | ❌ 不适合 |
| H5网页 | 开发快、跨平台 | 体验差、无法调用微信能力 | ⚠️ 部分适合 |
| 微信小程序 | 即开即用、微信生态、无需下载 | 受平台限制 | ✅ 最合适 |
选小程序的核心逻辑：
礼账是低频场景。用户不会天天记礼金，可能一个月打开一两次。低频场景的核心是“降低使用门槛”，而不是“增强功能”。
小程序“即开即用”的特性，完美匹配低频场景。
三、后端框架：为什么选Node.js？
| 方案 | 优点 | 缺点 | 是否适合 |
|---|---|---|---|
| Java (Spring Boot) | 生态成熟、性能好 | 开发慢、启动慢、资源消耗大 | ⚠️ 略重 |
| Go | 性能极好、并发强 | 生态不如Java成熟、学习曲线 | ⚠️ 可考虑 |
| Node.js (Express) | 开发快、轻量、JS全栈 | 单线程、CPU密集型任务弱 | ✅ 最合适 |
选Node.js的核心逻辑：
- 全栈同语言：小程序前端用JavaScript，后端也用JavaScript，不需要切换语言
- 开发速度快：Express框架成熟，npm生态丰富，能快速迭代
- 轻量：对独立开发者来说，Node.js的资源消耗和启动速度都优于Java
- 适合I/O密集型：简记往来的核心操作是数据库读写，Node.js的异步非阻塞模型很适合
四、数据库：为什么选MongoDB？
| 方案 | 优点 | 缺点 | 是否适合 |
|---|---|---|---|
| MySQL | 关系型、事务强、生态成熟 | Schema固定、扩展性受限 | ⚠️ 部分适合 |
| PostgreSQL | 功能强大、支持JSON | 复杂度高 | ⚠️ 略复杂 |
| MongoDB | Schema灵活、易扩展、文档型 | 事务弱于关系型 | ✅ 最合适 |
选MongoDB的核心逻辑：
- Schema灵活：礼账的数据结构可能会变化（比如后期加字段），MongoDB不需要迁移Schema
- 文档型存储：联系人+记录的关系，用文档型存储更自然
- 水平扩展：如果用户量增长到百万级，MongoDB的分片集群比MySQL的分库分表更容易实现
- 开发速度快：Mongoose ODM让数据库操作非常方便
五、技术栈总结
| 层级 | 技术选型 | 理由 |
|---|---|---|
| 前端 | 微信小程序原生 | 低频场景、即开即用 |
| 后端 | Node.js + Express | 全栈同语言、开发快、轻量 |
| 数据库 | MongoDB + Mongoose | Schema灵活、易扩展 |
| 部署 | 云服务器 + PM2 | 成本可控、运维简单 |
| 鉴权 | JWT | 无状态、易扩展 |
六、这套技术栈的实际运行数据
简记往来上线半年，这套技术栈支撑了：
- 6.8万用户
- 62万笔记录
- 日均请求量约2万次
- 核心查询响应时间稳定在150ms以内
- 服务器配置：2核4G
技术选型的核心原则：不追求“最好”，追求“最适合”。
下一篇，我们来聊聊微信小程序开发环境的搭建与工程化配置。
评论区聊聊：你的项目用的是什么技术栈？为什么选它？
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)