一、为什么这套架构不是“简单技术堆叠”？
很多电商系统介绍技术栈时，只是罗列：
● 用了什么框架
● 用了什么数据库
但真正有价值的问题是：
这些技术，是如何协同解决“复杂电商业务”的？
LikeShop 单商户 Java 版的设计核心不是“技术先进”，而是：
在可控复杂度下，支撑高频交易 + 营销规则 + 长期二开的能力
二、后端技术栈设计：稳定优先，而不是激进升级
1️⃣ 核心框架与架构模式
● 基础框架：Spring Boot 2.7.5
● 开发语言：Java 1.8
● 项目管理：Maven
● 架构模式：多模块分层架构
为什么是这套组合？
很多人会问：为什么不是更“新”的版本？
答案很现实：
电商系统优先考虑“稳定性 + 生态成熟度”，而不是版本新旧
Spring Boot 2.7.x + Java 8 的组合：
● 生态最成熟
● 兼容性最好
● 企业使用最广
👉 对电商来说，这意味着：
● 减少不可控问题
● 降低部署与运维风险
● 提高长期稳定性
多模块分层架构的意义
LikeShop 不是单体“代码堆”，而是：
通过模块化 + 分层，主动控制复杂度扩散
典型结构：
api（接口层）
↓
application（应用编排）
↓
domain（核心业务逻辑）
↓
infrastructure（数据与外部依赖）
👉 这带来一个关键能力：
复杂业务不会污染整个系统
三、数据库与数据访问：围绕“订单密集写入”优化
技术选型
● 数据库：MySQL 5.7.49
● ORM：MyBatis Plus 3.5.2
为什么不用更复杂的方案？
核心原因：
单商户系统的瓶颈，不在数据库类型，而在访问模式
MySQL 5.7 的优势：
● 成熟稳定
● 运维成本低
● 足以支撑大多数电商场景
MyBatis Plus 的价值
相比传统 ORM：
● 更接近 SQL（可控性强）
● 避免复杂 ORM 带来的性能问题
● 提供基础 CRUD 能力，减少重复代码
👉 关键点：
在电商系统中，SQL可控性 > ORM抽象能力
四、安全与认证：轻量但高性能的会话模型
技术选型
● 权限框架：Sa-Token 1.32.0
● 缓存支持：Redis（Sa-Token 集成）
为什么不是 Spring Security？
这是一个典型架构取舍问题：
Spring Security：
● 功能强大
● 体系复杂
● 学习成本高
Sa-Token：
● 轻量
● 易扩展
● 更适合业务型系统
👉 LikeShop 的选择本质是：
降低认证系统复杂度，把资源留给核心业务（订单与营销）
Redis 的作用：
● 会话存储
● 登录态共享
● 高并发访问支持
五、工具层设计：不是“方便”，而是“降低系统噪音”
技术选型
● JSON处理：Fastjson2 2.0.16
● 对象简化：Lombok 1.18.24
设计目的
这些工具的价值不在“省代码”，而在：
降低非业务复杂度，让核心逻辑更清晰
例如：
● JSON 高性能解析 → 减少序列化开销
● Lombok → 避免样板代码污染业务逻辑
六、前端架构：统一多端，而不是重复开发
管理后台（Admin）
● 技术栈：Vue 3 + TypeScript + Vite + Element Plus
● 状态管理：Pinia
👉 设计目标：
● 快速开发
● 强类型约束
● 高可维护性
移动端（核心用户侧）
● 技术栈：UniApp + Vue 3 + TypeScript
● 支持平台：
○ 微信小程序
○ 支付宝小程序
○ H5
为什么选择 UniApp？
核心原因不是“跨端”，而是：
用一套业务代码，覆盖多个流量入口
👉 对电商的意义：
● 活动同步上线
● 降低开发成本
● 保证体验一致性
七、真正的核心：复杂度如何被控制？
上面这些技术选型，最终服务于一个目标：
控制电商系统的复杂度增长
LikeShop 的关键策略是：
✔ 把复杂度集中在“订单 + 营销”
而不是：
● 分散在各模块
● 到处写业务逻辑
✔ 用分层架构隔离变化
● 上层负责流程
● 下层负责数据
● 核心层负责规则
✔ 用稳定技术栈降低风险
● 不追新
● 不堆技术
● 优先可控
八、核心结论
LikeShop 单商户 Java 架构的本质不是：
● 技术先进
● 框架新
而是：
在成熟技术栈下，通过结构设计控制复杂业务，使系统既能稳定运行，又能持续演进
最后
真正优秀的电商系统，不是用了多少新技术，而是能否在复杂业务下依然保持稳定与可控。
一句话总结
LikeShop 单商户 Java 架构通过成熟技术栈与分层设计，在保证稳定性的前提下，有效收敛电商业务复杂度，实现系统的长期可维护与可扩展。