1. 项目概述与核心需求
去年帮朋友改造他的线下服装店时，我深刻体会到传统零售业数字化转型的迫切性。当时我们用了三周时间，基于SpringBoot+Vue搭建的这套商城系统，成功让店铺线上订单量提升了300%。这个经历让我意识到，一个设计合理的电商系统对中小型服装商家有多重要。
这套网上服装商城管理系统采用经典的前后端分离架构，后端使用SpringBoot 3.1 + MyBatis-Plus 3.5，前端基于Vue 3 + Element Plus构建。系统最突出的特点是"轻量但完整"——在保持技术栈简洁的同时，覆盖了电商核心业务场景。比如我们特别设计的动态库存机制，可以实时同步秒杀活动中的库存变化，避免超卖问题。
2. 技术架构解析
2.1 后端技术栈设计
选择SpringBoot不是随大流，而是经过实际压测对比后的决定。在开发初期，我们测试过Quarkus和Micronaut等新框架，最终选择SpringBoot的原因有三：
- MyBatis-Plus的AR模式能极大简化商品CRUD操作
- Spring Security OAuth2对多端登录的天然支持
- 社区生态完善，遇到支付对接等问题时能找到现成解决方案
数据库方面，MySQL 8.0的JSON字段支持让我们能灵活存储商品规格参数。比如牛仔裤的尺码库存，我们采用这样的结构：
json复制{
"sizes": [
{"name": "S", "stock": 50},
{"name": "M", "stock": 30}
]
}
2.2 前端工程化实践
Vue 3的组合式API让前端开发效率提升明显。我们通过自定义Hooks实现了这些优化：
- useCartLogic：封装购物车增减、优惠券计算逻辑
- useSearch：集成Elasticsearch的模糊查询和筛选
- usePayment：统一处理微信/支付宝支付流程
特别值得一提的是基于WebSocket的实时通知系统，当订单状态变更时，前端会收到这样的推送：
javascript复制// 订单状态更新消息结构
{
event: 'ORDER_UPDATE',
data: {
orderId: '202312345',
newStatus: 'SHIPPED',
updateTime: '2025-03-20 14:30'
}
}
3. 核心功能实现细节
3.1 商品管理系统
商品管理模块采用了策略模式来处理不同类型的服装：
- 常规商品：标准库存管理
- 预售商品：基于定时任务的自动上架
- 限量商品：Redis分布式锁控制库存
商品搜索功能我们做了两级优化：
- 首字母拼音索引：将"牛仔裤"转为"nzk"存储，支持拼音首字母搜索
- 基于TF-IDF的权重计算：高频搜索词会自动提升排序
3.2 订单状态机设计
订单系统最复杂的是状态流转，我们定义了这样的状态机：
java复制// 订单状态枚举
public enum OrderStatus {
PENDING_PAYMENT, // 待支付
PAID, // 已支付
SHIPPED, // 已发货
COMPLETED, // 已完成
CANCELLED // 已取消
}
// 状态转换规则
stateMachine.configure()
.withExternal()
.source(OrderStatus.PENDING_PAYMENT)
.target(OrderStatus.PAID)
.event(OrderEvent.PAYMENT_RECEIVED)
.guard(ctx -> validatePayment(ctx));
4. 安全与性能优化
4.1 防御式编程实践
在安全方面我们做了这些特殊处理：
- 密码加密：PBKDF2WithHmacSHA256算法+随机盐值
- XSS防护：自定义Jackson过滤器处理富文本
- CSRF防护：SameSite Cookie + 关键操作二次验证
支付环节的防重放攻击方案值得分享：
java复制@PostMapping("/pay")
public Result pay(@Valid @RequestBody PaymentRequest request) {
// 检查时间戳（5分钟内有效）
if (System.currentTimeMillis() - request.getTimestamp() > 300_000) {
throw new BusinessException("请求已过期");
}
// 检查nonce是否已使用
if (redisTemplate.opsForValue().setIfAbsent(
"payment:nonce:" + request.getNonce(), "1", 5, TimeUnit.MINUTES)) {
// 处理支付逻辑
} else {
throw new BusinessException("重复请求");
}
}
4.2 性能调优记录
在高并发场景下，我们通过以下手段将QPS从200提升到1500+：
- 二级缓存设计：Caffeine本地缓存 + Redis集群
- 数据库优化：商品表采用VERTICAL分区，将详情描述单独存储
- 异步日志：通过Log4j2的AsyncLogger减少I/O阻塞
特别分享下商品详情页的缓存策略：
code复制Key格式：product:{id}:v{version}
缓存内容：
- 基础信息：60分钟
- 库存信息：10秒（通过Redisson的Pub/Sub实时更新）
- 评价统计：1小时
5. 部署与监控方案
5.1 容器化部署
我们采用Docker Compose编排服务，关键配置如下：
yaml复制services:
app:
image: openjdk:17-jdk
deploy:
resources:
limits:
cpus: '2'
memory: 2G
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"]
redis:
image: redis:7-alpine
command: redis-server --save 60 1 --loglevel warning
5.2 监控体系搭建
基于Prometheus + Grafana的监控看板包含这些关键指标：
- 业务指标：每分钟订单数、转化率
- 系统指标：JVM内存、MySQL线程数
- 异常监控：通过Sentry捕获前端错误
这是我们定义的告警规则示例：
yaml复制- alert: HighErrorRate
expr: rate(http_server_requests_errors_total[1m]) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate on {{ $labels.instance }}"
6. 开发经验与避坑指南
在项目开发过程中，我们积累的这些经验可能对你有用：
-
MyBatis的TypeHandler陷阱
处理商品规格JSON字段时，我们发现MyBatis默认的Jackson解析会丢失泛型信息。正确的做法是：java复制@MappedJdbcTypes(JdbcType.VARCHAR) public class SpecTypeHandler extends BaseTypeHandler<Map<String, SpecItem>> { // 实现时需要指定ObjectMapper的TypeFactory } -
Vue的响应式更新边界
在商品列表页，直接修改数组元素不会触发更新。应该使用：javascript复制// 错误方式 products[0].price = 99.9 // 正确方式 products.splice(0, 1, {...products[0], price: 99.9}) -
分布式事务处理
订单创建涉及多个服务时，我们最终采用Saga模式替代TCC，因为：- 服装行业对实时一致性要求不高
- 补偿事务的实现成本更低
- 更适应长周期业务（如预售订单）
这套系统目前已在3个服装品牌稳定运行，处理过日均5万+的订单量。如果你在实现过程中遇到具体问题，比如如何设计尺码选择组件，或者优惠券叠加计算逻辑，这些都是值得单独展开讨论的话题。