3. 技术选型与评估：后端框架、前端框架、数据库、缓存、消息队列选型
这一章咱们来聊点实在的。
技术选型，说白了就是拿着需求去挑工具。工具挑对了，后面开发顺风顺水；挑错了，后期重构能让你怀疑人生。我个人习惯把选型分成四个维度来考量：团队熟悉度、社区生态、性能与可扩展性、运维成本。
3.1 后端框架：别只看流行度，要看匹配度
我做过不少项目，从几十万用户的小系统到千万级并发的中台，后端框架的选择几乎每次都成了争论焦点。
目前主流的选择就那几个：Java系的Spring Boot、Go系的Gin/Go-Zero、Node.js系的Koa/Egg.js、Python系的FastAPI/Django。我的经验是：选框架就是选团队。
| 框架 | 优势 | 适合场景 | 避坑点 |
|---|---|---|---|
| Spring Boot | 生态完整，事务支持强，AOP优雅 | 企业级应用、复杂业务、事务密集型 | 内存占用偏高，启动慢 |
| Gin / Go-Zero | 高性能，编译快，微服务原生支持 | 高并发网关、中间件、基础服务 | 泛型支持晚，学习曲线陡 |
| Koa / Egg.js | 轻量，协程友好，全栈型 | 前后端分离、快速原型、BFF层 | TypeScript配置繁琐 |
| FastAPI / Django | 开发快，ORM强大，AI/ML集成好 | 数据密集型、内部工具、AI服务 | GIL限制，高并发需额外工具 |
个人建议：团队全是Java老手，别硬上Go。我见过一个团队因为追求“新潮”选了Go，结果连基本的事务回滚都折腾了一周。先看人，后看技术。
3.2 前端框架：一切为了研发效率
前端现在基本三足鼎立：React、Vue、Angular。我做过一个toB的后台管理系统，也做过toC的H5活动页，感触挺深。
- React：生态最强，灵活性极高。但注意，JSX和Hook的写法有一定心智负担。我当年从Class组件切到Hook时，中间有一周代码写得乱糟糟的。
- Vue：上手最平滑，适合中小型团队。模板语法直观，你想想看，新来的实习生第一天就能开始改页面，这多香。
- Angular：框得很死，适合大兵团作战。但学习曲线陡，我一般不推荐20人以下的团队选它。
曾经踩过一个坑：选型时只看了“流行度”，没考虑移动端兼容。项目到后期才发现React Native版本对某些国产安卓机兼容性差，补了无数patch。所以前端选型一定要问清楚：用户主要用什么设备访问？
3.3 数据库：选关系型还是NoSQL？我两边都要
这是个老生常谈的问题。但我给的答案很直接：核心业务数据用MySQL/PostgreSQL，辅助场景用NoSQL。
拿我们之前做的电商系统举例：
- 订单表、用户表、商品表：全部用MySQL，InnoDB引擎，事务保证一致性。这是底线，我不接受用MongoDB存钱。
- 商品评论、操作日志、用户行为轨迹：用MongoDB或Elasticsearch。写入量大，查询灵活，不要求强事务。
- 实时排行榜、库存扣减：用Redis。
| 数据库 | 强项 | 弱点 | 我常用的场景 |
|---|---|---|---|
| MySQL / TiDB | 强一致、事务、成熟 | 扩展成本高、写入瓶颈 | 账务、订单、用户 |
| PostgreSQL | JSON支持、GIS、自定义类型 | 主从复制弱于MySQL | 数据平台、地理信息 |
| MongoDB | 灵活Schema、高写入 | 无事务支持 | 日志、内容库、IoT |
| Elasticsearch | 全文检索、聚合分析 | 不擅长精确查询 | 搜索、日志分析 |
个人经验：一次项目中，团队图省事，用MongoDB做订单主库。上线后一个月，数据不一致的问题频发，最后花了两周用脚本修数据。从那以后，任何涉及金钱、库存、状态的系统，我坚持用关系型数据库做主库。
3.4 缓存：Redis永远是首选
缓存选型没什么悬念。Redis 基本是标配。Memcached现在用得越来越少，主要是数据类型太单一。
我一般这么用Redis：
- 热点数据缓存：比如首页商品列表、用户。
- 分布式锁：用Redisson或SETNX。
- 计数器/排行榜：Zset+SortedSet。
- 消息队列：Stream类型，轻量级场景足够。
注意：Redis不是万能的。我见过有人把大量未聚合的日志数据塞进Redis，结果内存爆了，导致整个系统卡死。缓存只存热点，你想想看，一次查询能撑住1000QPS就够了，别想着用它做持久化存储。
3.5 消息队列：选RocketMQ还是Kafka？看吞吐量
消息队列这题，我分成两个维度来选：
| 场景 | 推荐 | 为什么 |
|---|---|---|
| 业务解耦、事务消息、可靠性极高 | RocketMQ | 事务消息是原生支持，回查机制成熟 |
| 大数据管道、日志采集、高吞吐 | Kafka | 分区机制、顺序写入、吞吐量百万级 |
| 微服务间简单通信、少量节点 | RabbitMQ | 简单、稳定、运维友好 |
我做过一个订单履约系统，核心链路是：下单 -> 支付 -> 出库 -> 配送。这里面用了RocketMQ的事务消息来保证“支付成功”和“出库通知”的一致性。如果支付成功但出库没触发，那问题就大了。
个人习惯：消息队列的选型千万别只看并发数。我看重的是：消息不丢失、不会重复消费、能回滚。如果团队没人懂Kafka的调参，还是用RocketMQ省心。
3.6 本章小结
技术选型没有银弹。你看再多的对比文章，不如自己上手写一个Demo。我的建议是：用团队最熟悉的，做最保守的。等业务跑通了，再考虑逐步替换。
记住一句话：业务成功，技术才有价值；技术选型，永远是为业务服务的。