全栈开发实战复盘：哪些决策是对的，哪些是错的？

去年冬天的一个凌晨，我蹲在出租屋里对着屏幕发呆——闪仓进销存第一个版本上线三天了，用户数是零。代码写了三个月，数据库设计改了五版，结果连一个测试用户都没有。那一刻我怀疑自己：这些决策真的对吗？

TL;DR 创业第一年，我做了几十个技术决策，有些让我省了三个月时间，有些让我白费了两个月精力。今天复盘三个关键决策——技术选型、架构设计、AI集成——用亲身经历告诉你哪些是对的，哪些是错的。

技术选型：为什么我选了Spring Boot而不是Go？

选Spring Boot是对的，但没选微服务是错的。

说实话，刚辞职那会儿我纠结了很久。Go性能好、部署简单，适合SaaS；但Java生态成熟，我写过两年Spring Boot，上手快。最后选了Java，因为“先跑起来再说”。

后来我发现，这个选择帮我省了一个月。Spring Boot + MyBatis Plus + Vue 3这套组合我太熟了，CRUD写得飞快。但问题也来了——单机部署，所有模块耦合在一起。用户量一上来，性能瓶颈就暴露了。

有一次客户说“系统卡死了”，我查了半天才发现是采购模块的一个慢查询锁住了整个数据库。如果用了微服务，至少能隔离故障。不过话说回来，对于MVP阶段，单体应用确实更快。根据Stack Overflow 2024开发者调查，全栈开发者最常用的框架就是Spring Boot和Vue.js，这个选择至少让我在社区里能找到现成的解决方案^[1]。

架构设计：多租户SaaS到底该怎么搭？

用独立数据库是对的，但没做读写分离是错的。

做SaaS就得考虑多租户。我选了独立数据库方案——每个客户一个数据库。好处是数据隔离性好，坏处是维护成本高。后来有个客户说“报表加载太慢”，我一看，一个BI查询跑了8秒，因为全在一个库上执行。

如果当初做了读写分离，把查询流量引到从库，至少能快3倍。但我当时觉得“用户少，没必要”。结果用户从10个涨到50个时，性能直接崩了。

这就像健身——你总觉得“这个重量太轻，没必要加”，结果瓶颈期来了才后悔。后来我加了Redis缓存和数据库连接池优化，才勉强撑住。据IDC报告，云原生架构在中小企业中的渗透率从2020年的15%增长到了2025年的45%^[2]，我要是早一年用上云原生的读写分离方案，能少走很多弯路。

AI集成：该不该在MVP阶段就加AI？

加AI是对的，但选错了模型是错的。

2025年AI工具火得不行，GitHub Copilot让我的开发效率提升了至少30%^[3]。我脑子一热，给闪仓进销存加了个AI助手——用OpenAI的API，让用户问“这个月销量最好的产品是什么”就能自动生成报表。

结果呢？API调用成本一个月就烧掉2000块，而用户量才30个。而且OpenAI的响应延时高，用户等得不耐烦。后来我换成了本地部署的小模型（比如Qwen-7B），成本降了70%，速度也快了。

这个决策让我明白：AI要加，但要选对场景和模型。对于SaaS产品，高频低延时的场景用本地模型，低频高智能的场景再用云端大模型。Gartner预测，到2026年超过80%的企业将使用生成式AI API或部署生成式AI应用，但前提是选对技术路线。

从踩坑到成长

回看这一年，技术决策就像打游戏——你永远不知道哪个Boss会卡你一个月。但踩过的坑都是经验值。

说实话，如果让我重来一次，我会在架构设计上多花一周做读写分离，在AI集成上先用本地模型试水。但技术选型用Spring Boot，这个决定我到现在都不后悔。

要点回顾：

• 技术选型选熟悉的框架，先跑起来再说
• 架构设计要提前考虑扩展性，读写分离别等用户多了才做
• AI集成选对模型是关键，高频场景用本地模型
• 全栈开发就是不断试错，重要的是从每个决策中学到东西

---

参考来源

1. Stack Overflow 2024 开发者调查 — 全栈开发者最常用的框架是Spring Boot和Vue.js
2. IDC 云原生采用报告 — 云原生架构在中小企业中的渗透率从2020年的15%增长到2025年的45%
3. GitHub 2024 年报告：AI 辅助编程提升效率 — GitHub Copilot 使开发效率提升至少 30%