本文是「汽修 SaaS 开发连载」第 6 篇。前几篇讲了业务建模和并发控制，这篇回头看地基：技术栈怎么选的，哪些判断对了，哪些现在想改。
先列约束，再谈选型
技术选型最怕上来就比框架评分表。我们先把汽修场景的硬约束摆出来，选型是围绕这些约束做的：
- 门店网络不可靠。车间里手机信号时有时无，收银和开单不能因为断网就停摆。
- 写入集中在营业时段。白天工单、领料高频写入，凌晨几乎没流量，写入曲线非常陡。
- 团队要养得活。我们是小团队，选型必须考虑半年后招人能不能招到、社区资料多不多。
- 客户数据敏感。车牌、手机号、消费记录都在库里，SaaS 化之后数据安全没有退路。
整体形态：模块化单体，不是微服务
一开始团队里也有"直接上微服务"的声音，理由是后面要做连锁和开放平台。我们最后选了模块化单体（modular monolith），按领域拆模块，模块间只走接口调用：
┌─────────────────────────────────────────────┐ │ 应用层 │ │ PC 后台 API │ 技师 App API │ 小程序 API │ ├─────────────────────────────────────────────┤ │ order │ inventory │ archive │ member │ ... │ ← 领域模块，接口隔离 ├─────────────────────────────────────────────┤ │ 共享基础设施 │ │ 认证鉴权 / 消息队列 / 对象存储 / 定时任务 │ └─────────────────────────────────────────────┘理由写在这里，供同样规模的团队参考：多租户 SaaS 的复杂度在数据隔离和权限，不在服务拆分。第一阶段就把运维拆成十几个服务，等于把人力从业务功能挪去搭基础设施，客户看不到任何东西。微服务该拆的时候（比如后面报表和实时业务分库）再拆，单体的模块边界拆清楚，迁出去是顺手的；边界混乱的微服务往回收才是灾难。
主力组件和选它的理由
| 层 | 选型 | 关键理由 | 现在的评价 |
|---|---|---|---|
| 后端框架 | Spring Boot | 团队熟，事务和生态省事 | 对，没换的理由 |
| 数据库 | MySQL（InnoDB） | 事务强一致是进销存的刚需 | 对，领料扣减依赖行锁和条件更新 |
| 缓存 | Redis | 会话、权限缓存、号段发号 | 对 |
| 消息队列 | RabbitMQ | 工单事件广播（进度推送、凭证生成）起步量级足够 | 量再涨可能换，暂不折腾 |
| 对象存储 | 云 OSS | 维修照片视频，量大但访问低频 | 对，注意配好生命周期降冷 |
| 前端 PC | Vue + Element Plus | 后台表单密集型页面，组件全 | 对 |
| 技师端 | 微信小程序（口袋工具） | 免安装，车间扫码即用 | 半对，见下文 |
| 部署 | 云主机 + Docker Compose | 单客户版本迭代快 | P3 连锁阶段大概率要迁 K8s |
一个当时没想清楚的选型：技师端
技师端我们最初在"原生 App"和"小程序"之间犹豫，最后选了小程序，图的是免安装、发链接就能用。上线后两个真实反馈：
好的一面：推广成本确实低。让一个五十岁的钣金师傅装 App 很难，让他扫个码用小程序，教会只要两分钟。
问题的一面：车间弱网下小程序的体验比预期差，页面白屏时技师不知道是没网还是卡了。我们后来做了两层补救：工单列表和待办做本地缓存，断网可看；关键操作（报完工、领料）失败时有明确提示和自动重试。原生 App 的离线能力更强，但配套的推送、更新、多端发布成本对我们来说现阶段不划算。这个决定以后可能推翻，先记在这里。
数据库里最值钱的一个设计决定
选型文章一般不谈这个，但它比框架选择重要：我们从第一版就把tenant_id 写进了所有业务表，哪怕单店版根本用不上。
之前做别的项目吃过亏：单租户系统改多租户，全表加字段加索引，历史数据回填，前后折腾了一个多月。这次每个建表语句都带 tenant_id，查询拦截器自动拼租户条件。代价是几乎为零，收益在 P3 连锁阶段兑现。
有个细节：tenant_id 相关的索引必须放在联合索引最左，否则拦截器拼上条件后全表扫描。这条我们是在压测时发现的，一个没带 tenant_id 前缀的查询在 30 万行工单表上慢查询告警。
复盘：两处现在会改的
- 消息队列上得太早。初期事件量小，用 Spring 事件 + 本地表轮询完全够，RabbitMQ 的运维成本（镜像队列、告警配置）前三个月基本是纯负担。
- 报表一开始就独立数据源。这个反而是对的，忍住了"先共用业务库"的诱惑，后来写 BI 那篇会展开。
选型没有标准答案，约束不同答案就不同。如果你也在做类似的多门店 SaaS，欢迎评论区聊聊你们的团队规模和栈。
下一篇开始进连锁架构系列：多租户数据隔离，怎么做到"门店只看本店，总部可穿透"。
「汽修 SaaS 开发连载」· 06 / 05 领料扣库存的并发问题实战 · 04 单车利润需求让表结构推倒重来
