SKU复用靠SPU与SKU职责分离及规格维度正交组织，非类继承；SPU为模板（含spec_template），SKU为实例（含spec_value_ids、price、stock）；维度独立建表，SkuGeneratorService统一生成SKU。
电商系统里，sku 模型本身不是靠“继承”实现复用的，而是靠清晰的抽象分层和关系建模。所谓“最常用继承写法”，在数据库或后端逻辑中并不存在传统面向对象意义上的类继承；真正起作用的是 spu 与 sku 的职责分离 和 规格维度的正交组织。理解这一点，才能避免把模型设计带偏。
SPU 是抽象基类，SKU 是具体实例
SPU（Standard Product Unit）本质上就是商品的“模板”或“蓝图”。它不参与销售，只承载通用属性：品牌、类目、主图、描述、规格模板（JSON 定义可选维度）。SKU 则是这个模板生成的具体销售单元，每条 SKU 记录必须关联一个 SPU ID，并携带确定的规格组合值（如 color=黑色, size=L）、价格、库存等运营数据。
- SPU 表不存颜色/尺码字段，只存
spec_template字段，例如：[{"name":"颜色","values":["黑色","白色"]},{"name":"尺码","values":["M","L","XL"}] - SKU 表也不硬编码“颜色”“尺码”列，而是用
spec_value_ids（如"1_4"）或 JSON 字段记录所选规格值 ID 的有序路径，便于动态扩展维度 - 前端生成 SKU 表格时，正是基于 SPU 的
spec_template做笛卡尔积，再逐行绑定价格与库存 —— 这就是“模板复用”的实际体现
规格维度表结构要支持横向扩展
把“颜色”“尺码”这些属性拆成独立的维度表，而不是在 SKU 表里加一堆 varchar 字段，是保证高复用的关键。
-
product_attr_key表存规格类型：id、spu_id、name（如“颜色”） -
product_attr_value表存具体取值：id、attr_key_id、value_name（如“黑色”）、sort_order -
product_sku表通过attr_value_path（如 "101_205_309"）关联多个值，或用中间表sku_attr_mapping显式建模多对多 - 新增一个“材质”维度？只需往
product_attr_key插一条，再批量插入几个product_attr_value，无需改表结构、不干扰已有 SKU
SKU 数据操作统一收口，避免分散逻辑
所有 SKU 的生成、更新、校验都应由一个服务模块（如 SkuGeneratorService）集中处理，而不是让每个业务方自己拼 SQL 或遍历数组。
- 输入：SPU ID + 规格值 ID 数组（如 [101, 205, 309]）→ 输出唯一 SKU 记录（含 price、stock、code）
- 库存扣减、价格变更、上下架同步等操作，都基于 SKU ID 执行，不依赖前端传来的规格字符串解析
- 前端选择规格时高亮有效组合，其数据源
tags字段也是该服务预计算好的，不是运行时暴力遍历
前端表格与后端模型保持语义一致
用户看到的“SKU 表格”只是视图，它的行列结构完全由 SPU 的 spec_template 决定，不是固定 HTML 表格。生成逻辑如下：
- 读取 SPU 的规格模板 → 得到维度列表：[颜色, 尺码, 版本]
- 对每个维度取全部值 → 构成值集合：[["黑","白"], ["M","L"], ["标准版"]]
- 执行笛卡尔积 → 得到 2×2×1 = 4 条组合路径
- 每条路径映射为一行，price 和 stock 字段留空或回显历史值，供人工填写
- 提交时，后端按路径还原出对应规格值 ID，再调用
SkuGeneratorService创建或更新 SKU
