# Quickstart 验证: 商品规格

**Feature**: 013-food-spec | **Date**: 2026-07-15

> 手动端到端验证（项目无自动化测试）。接口契约见 [contracts/api.md](../contracts/api.md)，数据模型见 [data-model.md](../data-model.md)。

## 前置

1. 数据库已执行 `updatesql/sql.md` 中三张规格表的 DDL。
2. 存在一个门店（mdId=3）与至少一个商品（`pos_food` 记录）。
3. 商家账号 token 可用。

## 场景 1：规格模板管理

1. POST /chanting/foodSpec/saveFoodSpec，建"甜度"(单选/必选) + 规格值 无糖(0)/半糖(0)/全糖(0)。
2. GET /chanting/foodSpec/foodSpecPageList?mdId=3 → 列表含该规格及 3 个值。
3. GET /chanting/foodSpec/getSpecs?id={id} → 详情正确。
4. GET /chanting/foodSpec/changeOpen?id={id}&isOpen=false → 再查 getAvailableSpecsList 不含该规格。

**预期**：增删改查、启停、软删均生效；跨门店(mdId=4)查询不可见。

## 场景 2：商品挂规格

1. GET /chanting/foodSpec/getAvailableSpecsList?mdId=3 → 拿到可用规格。
2. POST /chanting/food/setposfood，商品带 foodSpecs=[甜度, 加料]。
3. GET /chanting/food/getfood?id={foodId} → 返回 foodSpecs 含甜度 + 加料。

**预期**：`food_spec_relation` 写入 2 条；`food_sku` JSON 同步更新；重新勾选（减为仅甜度）后关联更新为 1 条。

## 场景 3：列表返回规格

1. GET /chanting/food/getidlist（含该商品）→ 每条商品带 foodSpecs。
2. GET /chanting/food/stallFoodList、/foodSearch 同样带规格。

**预期**：列表注入规格结构完整、仅含启用项；无规格商品返回空规格。

## 场景 4：计价一致性

1. 顾客选 全糖(加价 0) + 珍珠(加价 5) 下单。
2. 检查订单快照 otherPrice = 5；订单单价 = 商品价 + 5。
3. 若参与促销，specPrice = 5 正确叠加。

**预期**：otherPrice / specPrice / 规格加价三者一致，金额 0 误差。

## 场景 5：兼容性

- 仅用旧 `food_sku` JSON（不经关联表）的历史商品：列表/详情仍能返回规格 JSON，不报错。
- 后台 add/edit 编辑商品：规格能正确持久化（FR-011）。