# Checklist: 促销 + 优惠券系统 — 整体需求质量

**Purpose**: 实施前预检，确保 spec/plan/tasks 可直接进入编码
**Created**: 2026-06-01
**Feature**: 008-promotion-coupon
**Depth**: Standard | **Actor**: Author (pre-implementation)

---

## 数据模型完整性

- [ ] CHK001 — 6张表的 DDL 是否都有完整字段定义（类型、长度、默认值、NOT NULL 约束）？ [Completeness, Spec §Data Model]
- [ ] CHK002 — promotion_activity_rule 表是否为每种促销类型（1~4）定义了清晰的字段使用映射（哪些字段有值、哪些为 NULL）？ [Clarity, Spec §Data Model]
- [ ] CHK003 — promotion_coupon_rule 表的 is_mutex 字段是否明确标注了"商品券时此字段含义为何"（商品券是否需要互斥属性）？ [Ambiguity, Spec §Data Model]
- [ ] CHK004 — promotion_user_coupon 的 expire_time 计算规则是否明确（receive_time + valid_days 天，含不含当天23:59:59）？ [Clarity, Spec §FR-010]
- [ ] CHK005 — pos_order_promotion 表的 promo_detail（JSON）是否定义了每种促销类型的标准 JSON schema？ [Completeness, Gap]
- [ ] CHK006 — 所有表的主键策略是否统一为 AUTO_INCREMENT？是否有表需要分布式 ID？ [Consistency, Spec §Data Model]

## 商家端功能需求

- [ ] CHK007 — 促销活动创建后，状态从"未开始"变为"进行中"的时机是否明确（创建时根据 startTime 判断 vs 定时任务）？ [Clarity, Spec §FR-001]
- [ ] CHK008 — "结束活动"操作是否可逆？结束后的活动能否重新激活？ [Gap, Spec §FR-005]
- [ ] CHK009 — 折扣商品的"折扣区"名称是否需要存储？还是纯前端展示概念？ [Clarity, Plan §Key Design Decisions 1]
- [ ] CHK010 — 优惠券创建时 remain_count 初始化为 total_count 的逻辑是否在 Service 层明确？ [Completeness, Tasks T025]
- [ ] CHK011 — 优惠券"下架"后已领取的券是否仍可使用？此行为是否在 spec 中明确？ [Edge Case, Spec §FR-009]
- [ ] CHK012 — 活动时间范围是否允许跨年或超长周期（如1年）？是否需要限制？ [Gap]
- [ ] CHK013 — 同一门店能否同时创建多个同类型的促销活动（如两个满减活动同时进行）？ [Ambiguity, Spec §互斥规则]

## 用户端接口需求

- [ ] CHK014 — 领券接口（FR-012）的并发控制是否定义？多人同时领取最后一张券时的处理策略？ [Edge Case, Gap]
- [ ] CHK015 — 查询门店可领券列表接口（FR-011）是否需要分页？ [Completeness, Plan §UserPromotionCouponController]
- [ ] CHK016 — "我的优惠券"接口（FR-013）是否需要返回券对应的门店名称？ [Completeness, Gap]
- [ ] CHK017 — 领券后有效期计算是否考虑了"当天剩余时间"（如23:50领券，valid_days=1，过期时间是明天23:59还是今天结束）？ [Ambiguity, Spec §FR-010]
- [ ] CHK018 — 用户券状态"已过期"是实时查询判断还是有定时任务批量更新？ [Clarity, Gap]

## 互斥规则与叠加

- [ ] CHK019 — 互斥规则"满减/折扣/第二份半价三选一"是否覆盖了门店同时有多个同类型活动的场景（如两个满减活动，选哪个）？ [Coverage, Spec §互斥规则]
- [ ] CHK020 — "新客立减"的"新客"定义是否明确（首次下单？首次在该门店下单？注册后N天内？）？ [Clarity, Spec §FR-004]
- [ ] CHK021 — 同享券和互斥券的叠加逻辑是否在算价接口 Response 中体现（互斥券选中后促销如何变化）？ [Consistency, Plan §UserPromotionCalcController]
- [ ] CHK022 — 商品券作用于指定商品时，如果订单中有多个该商品，是只优惠一个还是全部优惠？ [Ambiguity, Spec §FR-008]

## API 设计一致性

- [ ] CHK023 — 商家端 API 的分页参数格式（page/size vs pageNum/pageSize）是否与项目现有 Controller 一致？ [Consistency, Plan §ShPromotionActivityController]
- [ ] CHK024 — 用户端接口路径前缀 `/app/userPromotionCoupon` 是否与项目现有用户端接口路径风格一致？ [Consistency, Plan §UserPromotionCouponController]
- [ ] CHK025 — 所有接口的错误响应格式是否统一（code/msg/data 结构）？ [Consistency, Gap]
- [ ] CHK026 — 算价接口（POST /calculate）是否需要用户登录鉴权？商品价格由前端传入还是后端从数据库查？ [Completeness, Plan §UserPromotionCalcController]

## 范围与边界

- [ ] CHK027 — spec 中"不做"的清单（爆品、买赠、店外发券等）是否明确标注为"不做"而非"延后"？避免实施时混淆。 [Clarity, Spec §foodie 范围裁剪]
- [ ] CHK028 — pos_order 现有优惠字段（mdSalesReduction 等）在本期是否仍需写入？还是只写 pos_order_promotion 明细表？ [Ambiguity, Spec §Assumptions]
- [ ] CHK029 — 旧代码（SalesPromotion、VipQuanyi）的数据库表是否保留？是否有数据迁移需求？ [Gap, Spec §旧代码处理]
- [ ] CHK030 — PromotionUserCoupon 实体在 Phase 2 创建但无 Service，Phase 5.5 才补。是否有 Phase 间数据层断裂风险？ [Dependency, Tasks T007 → T039]

## 可测试性

- [ ] CHK031 — Success Criteria（SC-001~005）是否都可通过 Postman + 手动操作验证？还是有需要自动化测试覆盖的？ [Measurability, Spec §Success Criteria]
- [ ] CHK032 — 算价接口的 Response 示例是否覆盖了满减 + 折扣 + 新客立减 + 优惠券全部叠加的场景？ [Coverage, Plan §算价接口 Response]
- [ ] CHK033 — 是否有测试数据准备计划（哪些门店/商品/活动需要预创建）？ [Gap]
