「 简记往来」第三篇：技术选型——为什么选了微信小程序+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复杂度高⚠️ 略复杂MongoDBSchema灵活、易扩展、文档型事务弱于关系型✅最合适选MongoDB的核心逻辑Schema灵活礼账的数据结构可能会变化比如后期加字段MongoDB不需要迁移Schema文档型存储联系人记录的关系用文档型存储更自然水平扩展如果用户量增长到百万级MongoDB的分片集群比MySQL的分库分表更容易实现开发速度快Mongoose ODM让数据库操作非常方便五、技术栈总结层级技术选型理由前端微信小程序原生低频场景、即开即用后端Node.js Express全栈同语言、开发快、轻量数据库MongoDB MongooseSchema灵活、易扩展部署云服务器 PM2成本可控、运维简单鉴权JWT无状态、易扩展六、这套技术栈的实际运行数据简记往来上线半年这套技术栈支撑了6.8万用户62万笔记录日均请求量约2万次核心查询响应时间稳定在150ms以内服务器配置2核4G技术选型的核心原则不追求“最好”追求“最适合”。下一篇我们来聊聊微信小程序开发环境的搭建与工程化配置。评论区聊聊你的项目用的是什么技术栈为什么选它