SPU 与 SKU 的关系及主要字段拆分

S P U是商品大类；SKU是具体可售规格，其实，

金额字段为何要用 BigDecimal 而非 Number?

MVC 前端常用 JavaScript number 双精度浮点；怎么说呢，但金融计算要求十进制精度。Java 后端使用 BigDecimal ,MySQL 列类型为 DECIMAL. 例如：

@NotNull
@DecimalMin
@Digits
private BigDecimal salePrice;}

This ensures two decimal places without rounding surprises. 前端应将金额作为字符串提交，并限制两位小数；后端再做严格校验，防止「隐藏四舍五入」带来的财务损失。

并发安全的主要——乐观锁 + 单条 UPDATE 原子操作

• IDLE-LOOKUP vs IN-PLACE UPDATE：
• Lack of atomicity → race conditions.

A single SQL line guarantees that check and write happen toger in one transaction boundary enforced by DB engine.

创建 SKU 请求链路图

>Sec : POST /api/admin/products/{productId}/skus
Sec->>C : 校验 ADMIN 权限
C->>F : @Valid 校验 &> createSku
F->>P : requireById // product must exist
F->>S : existsBySkuCode // 防重复编码
F->S : new SkuEntity{…} // 初始化 price/stock/version
S->DB : INSERT mall_product_sku …其实，DB-->S : generated id &> init version
S-->F : toResponse
F-->C : ApiResponse
C-->UI : HTTP 201 Created + body
**Key Pain Points**:
- **SPU status guard** – Cannot add SKU to ON_SALE product → prevents accidental data exposure.
- **Uniqueness constraint** – Database index protects against concurrent duplicate inserts.
- **Front‑end ignorance of internal fields** – lockedStock/version are server‑managed.

改价请求链路图 
 B
B --> C
C --> D
D --> E // SQL includes WHERE version =?E --> F{rowsAffected==1}
F -- Yes --> G
F -- No --> H{current.version == expected}
H -- Yes --> I
H -- No --> J // fallback check in code
SQL snippet:
@Update("""
UPDATE mall_product_sku SET sale_price = #{salePrice}。version = version + 1,updated_at = CURRENT_TIMESTAMP
WHERE id = #{skuId}
AND version = #{expectedVersion}
""")
int updatePriceByVersion(Long skuId,BigDecimal salePrice,Integer expectedVersion);

调库存请求链路图 
 B
B --> C
C --> D
D --> E{adjustAvailableStockByVersion}
E --> F{rowsAffected==1}
F -- Yes --> G
F -- No -->
subgraph ConflictReason
H1{{current.version!老实说，= expected}} -.-> H2
H3{{current.availableStock + delta <0}} -.-> H4
end
SQL snippet:
@Update("""
UPDATE mall_product_sku SET available_stock = available_stock + #{delta},version = version + 1。updated_at = CURRENT_TIMESTAMP
WHERE id = #{skuId}
AND version = #{expectedVersion}
AND available_stock + #{delta}>= 0
""")
int adjustAvailableStockByVersion(Long skuId,Integer delta,Integer expectedVersion);

订单相关锁定/释放流程预览 





创建订单时锁定🟢🔒🟢 → 🔒🟢🔒'
lockStock / SkuMapper.lockStock 
quantity。skuId,当前可售足够?
WHERE availablestock>= quantity 
available -= quantity;locked += quantity 

取消订单时释放🔒🟢 → 🟢🔒🟢'
releaseLockedStock / SkuMapper.releaseLockedStock 
quantity。
skuId,当前锁定足够?WHERE lockedstock>= quantity 
available += quantity;locked -= quantity 

支付成功确认售出🔒🟢 → ✖️🔒'
 






...



测试驱动开发的关键性"



SkuControllerTest – 验证 HTTP 行为、参数校验、权限和业务代码返回值。

SkuConcurrencyTest – 确认同一版本下仅能有一次成功调整，用两线程同时扣减演示效果。

SkuMapperTest – 检测 MyBatis‑Plus 乐观锁插件是否正常工作，还有自定义 SQL 的正确性。怎么说呢，

ProductDaoTest – 验证产品状态过滤逻辑是否生效。




说到*Tip*。在开发中先跑这些单元/集成测试可以迅速定位 “版本冲突” 或 “库存不足” 等典型错误，而不是在生产日志里追踪到底是哪里出了问题。其实，*这就是最短方法解决使用者痛点*。老实说，---

前端错误处理示例"
ts
// 错误码 -> UI 消息映射
const errorMap:{ : string }={
INVENTORY_VERSION_CONFLICT:'数据已被他人修改。请刷新后重试',INSUFFICIENT_STOCK:'当前可售库存不足，请检查数量',SKU_CODE_ALREADY_EXISTS:'SKU 编码已存在请换一个名称',};function handleError{
const msg=document.createElement;msg.className='toast';msg.textContent=value||'操作失败，请稍候再试';document.body.appendChild;}
*Why this matters*: 当后台返回 `INVENTORY_VERSION_CONFLICT` 时如果前端继续使用旧 `version` 重试，会
冲突；如果返回 `INSUFFICIENT_STOCK`，前端应该立即重新拉取最新库存而不是假设自己已扣完。---

说到接下来预告，购物车模块 "

我们学习如何把“前端临时状态”转化为持久化记录。而且要保证:



Shelfability check again at backend side for every cart item.
• 使用者是否登录？怎么说呢，• 商品/SKU 是否仍然 ON_SALE？• 是否存在相同使用者+SKU 的已有行？• 数量范围是否合法，• 最终展示价格是否采用快照还是实时价？​
• 锁定库存只在下单时触发，不会影响后台手动调库行为。​
● 为了避免「先读 再写」产生的数据竞争，在 CartFacade 中也会使用乐观锁或原子 UPDATE 来完成数量增删。



​

至于要点。" "



S P U 与 S K U 明确拆分，每个表承担自己的职责。按理说，② 金额字段必须使用 BigDecimal/DECIMAL。③ 创建 SKU 时只能传入业务必需字段；lockedStock/version/time 是服务器自动维护。④ 已上架商品禁止随意新增 SKU，以避免线上混乱。⑤ 每一次改价或调库都携带 
expectedVersion
⑥ 调库更新必须是单条 SQL 且包含 available_stock + delta>= 0 && version= 条件才执行，否则返回不同 error code。⑦ 并发敏感更新一定检查 affectedRows == 1；否则抛 conflict 或 insufficient stock。⑧ 后台调库与订单产生的锁定都采用三段式流程，确保订单流转不会出现超卖或欠缺。







如果你能在没有代码旁边直接解释“两个线程同时扣除同一份版本。只能有一次成功”，还有为什么“禁用按钮不等于数据库安全”，那你已经跨过了电商程序最难的第一关！