sku 应独立成表并与商品主表关联，属性抽象为 attribute 表、值存 attribute_value 表，组合通过 sku_attribute_value 中间表实现，禁用 json 或字段堆叠；goods 表只存通用信息，price/stock 等 sku 级字段必须下移；attribute 表需加 sort_order 保证组合生成一致性。
SKU 数据不能硬编码进商品表字段
把颜色、尺码、库存全塞进 goods 表加一堆 color_1、size_s_stock 字段，短期看着省事，后期一加新属性（比如“裤长”“领型”）就得改表结构，连带所有业务逻辑全得动。电商属性组合爆炸式增长，靠字段堆叠根本不可持续。
- 每个 SKU 实际是「属性值组合」的唯一实例，应独立成表，和商品主表用
goods_id关联 - 属性本身（如“颜色”“尺码”）要抽象为
attribute表，值存attribute_value，避免字符串重复和拼写不一致 -
sku表只存组合结果：一个sku_id对应一组attribute_value_id，通过中间表sku_attribute_value关联
用中间表关联属性值，别用 JSON 字段存组合
有人图快，直接在 sku 表里加个 spec_json 字段存 {"color": "red", "size": "M"} —— 查询会变慢，没法走索引，更没法按“所有红色 SKU”这种条件高效筛选。
- 必须拆成三张表：
sku（主键、价格、库存等 SKU 级数据）、attribute_value（属性值 ID、名称、所属属性 ID）、sku_attribute_value（sku_id+attribute_value_id，联合唯一） - 查“某商品下所有红色 SKU”，SQL 是
SELECT s.* FROM sku s JOIN sku_attribute_value sav ON s.sku_id = sav.sku_id JOIN attribute_value av ON sav.attribute_value_id = av.id WHERE av.value = '红色' AND s.goods_id = 123 - 给
sku_attribute_value(sku_id, attribute_value_id)加联合索引，查询性能才稳
商品主表只存通用信息，SKU 级字段坚决不下放
goods 表里如果出现 price、stock、image_url 这类字段，就说明设计已经错位了——不同 SKU 价格可能不同（如赠品价）、库存肯定独立、主图也许一样，但详情图/视频可能因规格而异。
-
goods表只保留：名称、品牌、类目、基础描述、默认主图、是否上架等全局属性 -
price、stock、cost_price、weight、sku_code全部移到sku表 - 图片资源若需按 SKU 区分，另建
sku_image表，而不是在goods表里留个“SKU 图片数组”字段
批量导入或前端选规格时，属性值顺序影响组合生成
用户看到的“颜色 → 尺码 → 版型”下拉顺序，不是 UI 层随便排的，它直接影响后端生成 SKU 组合的可预测性。如果数据库里属性没排序权重，导出 Excel 模板时容易漏填、填反，导致生成无效组合。
- 在
attribute表加sort_order字段，明确“颜色”排第 1，“尺码”排第 2，“版型”排第 3 - 生成 SKU 组合时，按
sort_order升序拼接attribute_value_id，确保同一组值每次生成的sku_id一致（便于幂等处理） - 前端渲染规格选择器时，也按这个顺序取值，避免用户选了“M 红色”却生成出不存在的 SKU
属性组合的爆炸性增长不是理论问题，是上线两周后加个“包装类型”就让 SKU 数翻倍的真实压力。字段冗余、JSON 存组合、主子表职责混淆，这三处只要踩中一个，后续改起来就是锁表+停服+人工补数据。
