进销存 Web 版技术架构选型
技术选型没有银弹，但有明确的约束条件：进销存是重表单、重表格、重交互的业务系统，团队规模小、交付周期紧、需要长期维护。本文按这个约束，把每个技术决策的对比和结论讲清楚，供同类项目参考。
一、整体架构：前后端分离 + 单体后端
第一层决策是架构形态。我们的选择：前端 SPA + 后端单体应用，不做微服务。
- 前后端分离：前端专注交互，后端专注业务，接口契约用 OpenAPI 固定（见 REST API 设计）。分离让前端能独立 Docker 化部署，也让将来做移动端复用同一套 API。
- 单体后端：进销存业务模块间耦合紧密——订单影响库存、库存影响成本、成本影响报表，微服务的分布式事务成本远大于收益。单体 + 清晰的模块边界（按业务域分包），两三人的团队维护五年没有问题。真到单实例撑不住那天，按模块拆分也有清晰的刀口。
二、前端选型：Vue3 + Vite + TypeScript
| 候选 | 优势 | 劣势 | 结论 |
|---|---|---|---|
| Vue3 | 国内人才多、中文资料全、模板语法上手快 | 大型工程生态弱于 React | 选用 |
| React | 生态最大、企业级方案成熟 | 团队学习成本高，表单密集场景样板代码多 | 备选 |
| 传统多页 + jQuery | 零构建、兼容老旧环境 | 复杂交互开发效率低，招不到愿意维护的人 | 放弃 |
配套三件套：Vite（秒级热更新、生产构建快）、TypeScript（进销存单据字段几十个，类型安全能在重构时保命）、Pinia（比 Vuex 简单，组合式 API 风格）。UI 组件库选 Element Plus——表格组件是它最强项，而进销存页面一半以上是表格。
三、后端选型：Spring Boot 或 NestJS
两条路线都验证过可行性，按团队背景二选一：
- Java + Spring Boot：进销存客户多为传统企业，客户侧运维对 Java 接受度最高；事务、并发、生态最成熟。适合有 Java 背景的团队。
- TypeScript + NestJS：和前端同语言，全栈 TypeScript 类型可共享；单体结构成熟。适合前端起家的团队。
无论哪条，三个技术件不变：数据库迁移工具（结构演进靠它）、统一响应封装和幂等设计（见 API 篇）、以及预聚合报表机制（见 报表可视化）。这些是进销存后端的价值核心，框架只是壳。
四、数据库与缓存
MySQL 8 是默认答案：单机性能足够支撑年单量千万级的进销存，InnoDB 事务可靠，运维人才遍地。除非客户已有 PostgreSQL 运维体系，否则不为小众偏好增加交付风险。
Redis 两个用途：一是会话与 Token 缓存，二是热点数据缓存（商品档案全表就几万条，进程内缓存 + Redis 各存一份，前端查询基本零延迟）。注意 Redis 不参与任何金额计算，账本只信数据库事务。
五、PWA 与离线层的定位
PWA 不是可选项，是 Web 版进销存替代本地软件的关键能力（详见 PWA 离线实践）。但离线层要控制复杂度：只缓存应用外壳和基础档案，单据同步走队列 + UUID 幂等，不做双向实时同步——那是另一个量级的工程。
六、选型清单总结
前端：Vue3 + Vite + TypeScript + Pinia + Element Plus
后端：Spring Boot（或 NestJS）+ MySQL 8 + Redis
部署：Docker Compose（nginx + 后端 + 数据库）
离线：Service Worker + IndexedDB（PWA）
接口：OpenAPI 3 契约 + 统一响应信封 + 幂等键这套组合没有追新，每一项都在"团队能驾驭"和"生态够成熟"的交集里。选型的本质是在约束条件下做减法——能一个框架解决的，绝不引入第二个。
结语
技术架构选型的验证标准不是发布会上的 benchmark，而是三年后还能不能顺利招到人、顺利发新版、顺利给客户交付。围绕这个目标，本文的组合是稳妥答案；如果你的团队约束不同，决策方法比结论更重要。