订单类设计需区分业务属性与流程状态，用枚举定义orderstatus，instant类型存时间戳，拆分orderitem避免冗余；缓存用concurrenthashmap+computeifabsent；状态流转用枚举内置迁移表校验；分页改游标式并建联合索引；订单号用雪花算法，支付幂等靠联合唯一索引。
订单类怎么设计才够用又不臃肿
订单核心字段不能只按数据库表照搬，得区分「业务属性」和「流程状态」。比如 orderStatus 用枚举比字符串安全，createTime 和 updateTime 必须是 Instant 类型（不是 Date 或 LocalDateTime），避免时区错乱。
常见错误：把商品明细直接塞进 Order 类里用 List<string></string> 存 SKU，结果没法查数量、价格、是否已发货。正确做法是拆出 OrderItem 类，和 Order 建立一对多关系。
-
Order只保留订单号、用户ID、总金额、状态、时间戳、收货信息 -
OrderItem包含商品ID、数量、单价、快照名称（防止商品下架后查不到） - 避免在
Order里放getTotalPrice()这类计算逻辑——它该由服务层聚合，类本身保持贫血
用HashMap还是Map接口声明订单缓存
本地缓存订单数据时，别直接写 HashMap<string order> cache = new HashMap();</string>。接口编程更利于后续替换（比如换成 Caffeine 或加过期策略）。
更关键的是线程安全：如果多个线程同时下单查缓存，HashMap 会崩溃。开发阶段用 ConcurrentHashMap 是底线，但注意它不保证复合操作原子性（比如“查无再put”得用 computeIfAbsent()）。
立即学习“Java免费学习笔记（深入）”；
private final Map<String, Order> orderCache = new ConcurrentHashMap<>(); <p>// 安全的“取或创建” Order order = orderCache.computeIfAbsent(orderId, id -> loadFromDB(id));
- 不要用
static HashMap模拟全局缓存——测试难、内存泄漏风险高 - 缓存 key 建议用
"ORDER:" + orderId格式，为将来迁移到 Redis 留余地 - 小型系统可不加 TTL，但必须有清除机制（比如订单完成 7 天后异步清理）
订单状态流转为什么不能靠 if-else 堆出来
订单从“待支付”→“已支付”→“已发货”→“已完成”，看似简单，但硬编码状态校验会迅速失控。比如“已取消”只能从“待支付”或“已支付”转，“已完成”不可逆——这些规则散落在各个 service 方法里，改一个就漏一个。
推荐用状态机轻量方案：Apache Commons Lang 的 EnumStateMachine 太重，直接用枚举自带的状态迁移表更可控。
public enum OrderStatus {
PENDING, PAID, SHIPPED, COMPLETED, CANCELLED;
<pre class='brush:java;toolbar:false;'>// 定义合法转移：PENDING → PAID, PENDING → CANCELLED...
private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = Map.of(
PENDING, Set.of(PAID, CANCELLED),
PAID, Set.of(SHIPPED, CANCELLED),
SHIPPED, Set.of(COMPLETED)
);
public boolean canTransitionTo(OrderStatus next) {
return TRANSITIONS.getOrDefault(this, Set.of()).contains(next);
}}
- 每次更新状态前调用
if (!oldStatus.canTransitionTo(newStatus)) throw new IllegalStateException(...); - 数据库字段仍用
VARCHAR(20)存枚举名（如"PAID"），别存序号——可读性差、重构危险 - 日志里必须记录状态变更前后的值，否则生产环境排查“谁把订单改成已发货”毫无头绪
MyBatis 查询订单列表时分页为什么总慢
不是 LIMIT 10 OFFSET 1000 本身的问题，而是没避开“深度分页陷阱”。当查第 100 页（每页 10 条），MySQL 实际要扫描 1000 行再丢弃前 990 行。
小型系统不用上 Elasticsearch，但至少改用游标分页（cursor-based pagination）：用上一页最后一条的 createTime 和 orderId 作为下一页条件。
<!-- 把 offset 分页换成 where createTime < ? AND orderId < ? ORDER BY createTime DESC, orderId DESC LIMIT 10 -->
SELECT * FROM orders
WHERE status = #{status}
AND create_time < #{lastCreateTime}
AND (create_time != #{lastCreateTime} OR order_id < #{lastOrderId})
ORDER BY create_time DESC, order_id DESC
LIMIT 10- 必须给
(status, create_time, order_id)建联合索引，否则查询还是走全表 -
前端传参别叫
page和size，改用cursor（Base64 编码的lastCreateTime + lastOrderId） - 第一次请求不带 cursor，默认查最新 10 条；后续请求必须带，否则不准
真实项目里最常被跳过的，是订单号生成的唯一性保障和幂等处理。UUID 太长，数据库主键用自增 ID 又暴露业务量——用雪花算法（SnowflakeIdGenerator）或数据库号段模式才是小系统合理起点。而支付回调重复触发，靠 order_id + pay_channel + trade_no 联合唯一索引就能拦住 90% 的重复入库。
