订单类设计需分离业务生命周期：Order仅存orderId（String）、customerId、orderTime（@CreatedDate）、status（枚举）、totalAmount（BigDecimal）；OrderItem须拆表并存快照数据（skuName、unitPrice、quantity、discountAmount、lockedStock）。
订单类怎么设计才不漏关键字段
订单系统最怕后期加字段，比如一开始没留支付状态、发货时间，后面改起来牵一发动全身。核心是把业务生命周期拆清楚：Order 本身只管「谁在什么时候下了什么」，不混入支付、物流细节。
必须包含的字段有：orderId（建议用 String，兼容雪花ID或UUID）、customerId、orderTime（LocalDateTime）、status（枚举，如 PENDING/PAID/SHIPPED）、totalAmount（用 BigDecimal，别用 double）。
容易踩的坑：
-
status别用int或String，后期状态流转逻辑会散落在各处；定义enum OrderStatus，并在Order中强制校验状态迁移合法性 - 别在
Order里直接嵌套List<orderitem></orderitem>后又手写 JSON 序列化——JPA/Hibernate 默认支持，但 MyBatis 需显式配置@OneToMany和resultMap - 如果用 Spring Boot，
orderTime字段加@CreatedDate，避免手动赋值出错
订单项（OrderItem）为什么不能和订单共用一张表
一对多关系硬塞进单表，会导致重复存储客户信息、订单头信息，且无法单独查某商品销量。必须拆成两张表：order 和 order_item，外键 order_id 关联。
立即学习“Java免费学习笔记（深入）”；
关键点：
智能代理搜索。多源检索置信度评分 - 统一API整合网络、学术和Tavily搜索。
-
OrderItem必须存快照数据：即下单时的skuName、unitPrice（BigDecimal）、quantity，不能只存productId后期去查——商品名/价变了，历史订单就对不上 - 别忽略
discountAmount字段：促销场景下，每项可能独立优惠，总金额 ≠ ∑(单价 × 数量) - 如果要做库存预占，
OrderItem建议加lockedStock字段，并在创建时扣减，避免超卖
Spring Boot + JPA 下怎么安全地保存订单和订单项
JPA 级联保存看着方便，但默认 CascadeType.PERSIST 容易掩盖主键生成顺序问题——比如 Order 用数据库自增 ID，而 OrderItem 的外键还没赋值就先 persist，会报 org.hibernate.TransientPropertyValueException。
实操建议：
- 用
@GeneratedValue(strategy = GenerationType.IDENTITY)时，先save(order)，再手动 setorderId到每个OrderItem，最后saveAll(items) - 更稳妥的是换用
GenerationType.SEQUENCE或 UUID：在构造Order时就生成orderId，再 newOrderItem并关联，一次save(order)即可（前提是@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)） - 事务必须包裹整个流程：
@Transactional加在 service 方法上，否则订单存了、订单项失败，数据就脏了
查询订单列表时为什么连表容易 OOM
一个订单平均 3–5 个商品，100 条订单查出来就是几百条记录，用 @Query 写 JOIN 加 FETCH，Hibernate 默认会把所有字段全加载进内存，List
解决方案分场景：
- 后台订单列表页（只看订单头）：用原生 SQL 或
@Query查order表，必要字段用Object[]或自定义 DTO（如OrderSummary），避开实体映射 - 详情页需要订单+明细：用
@EntityGraph显式指定加载orderItems，并配@Fetch(FetchMode.JOIN)，同时加@QueryHints(@QueryHint(name = "org.hibernate.fetchSize", value = "50"))控制 JDBC fetch size - 千万别用
LAZY = false全局设成急加载——看似省事，实际让所有无关查询都拖着明细一起查
复杂点在于状态校验和库存回滚：订单取消时，得同步释放预占库存，且这个操作不能和数据库事务绑死（库存可能是另一个服务），得用本地消息表或 Saga 模式。这点多数人一开始会忽略，等并发取消时才发现库存扣没了却没还回来。
