TakeoutSaaS.Prototypes/Cend-MiniProgram-Prototype/docs/11-V1.0页面开发执行清单与验收标准.md

V1.0 页面开发执行清单与验收标准

• 文档版本：V1.0
• 基线日期：2026-03-16
• 适用项目：TakeoutSaaS 小程序 C 端
• 对应前端仓库：D:\HAZCode\TakeoutSaaS\TakeoutSaaS.C-Side-Mini-Program-V1
• 对应原型目录：D:\HAZCode\TakeoutSaaS\TakeoutSaaS.Prototypes\Cend-MiniProgram-Prototype
• 对应冻结文档：
  • docs/05-页面清单总表.md
  • docs/07-页面规格
  • docs/09-租户后台与C端功能映射总表.md
  • docs/10-全周期研发实施顺序与交付清单.md
• 文档目标：把“当前正式仓库真实已有内容”与“当前已经冻结的新页面职责”对齐，形成可以直接拿来排开发顺序、做验收的执行版清单。

---

1. 这份文档现在负责什么

这份文档只解决 4 件事：

1. 当前正式小程序仓库到底已经有了哪些页面、组件、服务和 store。
2. 这些已有内容距离当前冻结规格还差什么。
3. 这一轮应该按什么顺序补，不再按旧文档里的过期状态推进。
4. 每一项补到什么程度，才算可以进入下一项。

这份文档不再做两类事情：

• 不再把“运行时是 mock 还是真接口”写死成长期结论。
• 不再把“页面文件是否存在”和“页面职责是否完成”混成一件事。

---

2. 当前正式仓库真实基线

本节基于以下代码现状整理：

• src/app.config.ts
• src/pages/**
• src/components/**
• src/services/mini.ts
• src/stores/**

2.1 已注册页面路由

当前 src/app.config.ts 已注册 10 个页面，说明这些页面都已经进入正式仓库，而不是“未实现”。

编码	页面名称	路由	当前成熟度	当前主要缺口
T01	首页	pages/home/index	已有业务化骨架	还未完全收口为“门店上下文 + 动态活动 + 推荐导流”首页
T02	点餐页	pages/menu/index	主交易页最小闭环已具备	还需严格对齐新规格中的渠道类目、商品分流、活动摘要
T03	订单页	pages/orders/index	最小订单列表已具备	还需改成顾客任务语言和状态动作闭环
T04	我的页	pages/profile/index	已有占位和联调页能力	还未收口为聚合页，不应继续维持“开发说明页”形态
P01	门店选择页	pages/store/select/index	最小可用	还缺搜索、场景过滤、不可用门店表达、最近门店表达
P02	地址管理页	pages/address/index	已有最小地址表单	还不是完整地址列表与选择页
P03	结算确认页	pages/trade/checkout/index	已有试算、校验、建单、模拟支付链路	还需按新规格收口场景卡、优惠结构、备注区、支付表达
P04	支付成功页	pages/trade/success/index	已有最小结果页	还需加强订单摘要、场景差异和兜底回流
P05	订单详情页	pages/order/detail/index	已有最小详情页	还需补齐履约时间轴、费用明细和状态动作区
P18	堂食扫码确认页	pages/dinein/confirm/index	已有最小桌号确认页	还不是冻结后的“扫码确认页”结构

2.2 已存在的关键组件

旧文档把 C01 / C02 写成了“未实现”，这一点已经不准确。当前正式仓库中两者都已经存在，并且已经接入点餐页。

编码	组件名称	代码入口	当前成熟度	当前主要缺口
C01	商品详情抽屉	src/components/spec-popup/index.vue	已存在并接入点餐页	还需按新规格补齐商品详情信息、组合商品选择、禁选逻辑
C02	购物车抽屉	src/components/cart-drawer/index.vue	已存在并接入点餐页	还需按新规格补齐凑单提示、优惠摘要、空态联动和结算承接

补充说明：

• 点餐页 当前已经不是“只有商品列表，没有抽屉组件”的阶段。
• 当前更准确的判断是：已有最小组件和接入关系，但还没有完全对齐冻结规格。

2.3 当前服务层能力

当前 src/services/mini.ts 已具备以下前端服务封装：

服务函数	能力说明	当前结论
getMiniBootstrap()	启动引导、租户和场景上下文	已具备
getStores()	门店列表	已具备
getCategories()	类目列表	已具备
getMenu()	菜单列表	已具备
getProductDetail()	商品详情	已具备
estimatePrice()	金额试算	已具备
checkoutValidate()	结算校验	已具备
createOrder()	创建订单	已具备
mockPayOrder()	模拟支付	已具备
getOrders()	订单列表	已具备
getOrderDetail()	订单详情	已具备

这里要明确两个边界：

1. “服务函数已存在”不等于“所有后端接口都已经联真”。
2. 本文只冻结前端 repo 的能力基线，运行时是否走 mock 以环境和后端 readiness 为准，不再写成会过期的绝对结论。

2.4 当前 store 分工

旧文档只写了 appStore / cartStore，这也已经过期。当前仓库已经有 4 个核心状态域。

store	当前职责	当前结论
appStore	租户、门店、场景、bootstrap、全局上下文	已具备
cartStore	购物车商品、数量、金额汇总	已具备
customerStore	顾客基础信息，如姓名、手机号	已具备
fulfillmentStore	履约上下文，如地址、桌号	已具备

当前更合理的判断不是“还没有地址和顾客状态 store”，而是：

• 已经有 customerStore / fulfillmentStore 作为最小状态承接。
• 还没有把它们扩成完整的地址簿、身份中心、履约域模型。

---

3. 当前冻结结论下，必须守住的实现边界

这一节不是重复 docs/07，而是提炼成编码和验收时不能再跑偏的硬边界。

3.1 首页边界

• 首页是 门店上下文 + 场景切换 + 动态导流 + 推荐承接 页面。
• 首页不是固定八宫格活动页。
• 首页不是资产目录页。
• 首页不是规则说明页。

3.2 点餐与商品边界

• 场景切换必须受门店 serviceTypes 约束，不做固定三按钮硬编码。
• 类目展示必须跟随当前渠道和场景，不做静态类目。
• 简单商品才允许直接加购。
• 套餐或复杂商品必须经过规格 / 组合选择，不得直接跳过。

3.3 结算边界

• 结算页必须拆开：
  • 手动资产：优惠券、余额、次卡
  • 自动优惠：满减、新客、会员折扣、免配送费
• 积分抵扣 当前不是已冻结结算能力，不能先写死进主流程。
• 当前支付方式页面表达只冻结：
  • 微信支付
  • 余额支付

3.4 订单与售后边界

• 订单页必须用顾客任务语言，而不是商家看板列名。
• 商家操作不属于顾客端页面。
• 催单 / 骑手轨迹 / 取餐码 当前都不作为固定必做能力写死。

3.5 我的页与资产边界

• 我的页是聚合页，不是资产真源页。
• 优惠券数、未读消息数、次卡实例数等不稳定字段不先冻结为首页级硬依赖。
• 后台的“消息触达中心”不是顾客端“消息收件箱”。

3.6 活动与增长边界

• 当前值得独立页面承接的活动只冻结：
  • 领券中心
  • 秒杀活动
  • 限时折扣活动
• 满减和新客礼更偏规则结果展示，不先做重页面。

---

4. 本轮执行范围

本轮执行范围只覆盖“当前正式仓库已注册页面 + 已接入关键组件”的收口工作。

4.1 本轮必须收口

• T01 首页
• T02 点餐页
• T03 订单页
• T04 我的页
• P01 门店选择页
• P02 地址管理页
• P03 结算确认页
• P04 支付成功页
• P05 订单详情页
• P18 堂食扫码确认页
• C01 商品详情抽屉
• C02 购物车抽屉

4.2 本轮明确不扩

以下内容仍然在全周期规划内，但不应该在当前这份执行清单里抢主线：

• P06 退款申请页
• P07 退款详情页
• P08 评价页
• P09 领券中心页
• P10 秒杀活动页
• P11 限时折扣活动页
• P12 会员中心页
• P13 积分商城页
• P14 储值充值页
• P15 次卡页
• P16 消息中心页
• P17 帮助中心页

这些页面不是删掉，也不是否定，而是要等当前注册页面和主交易链路先收口。

---

5. 推荐执行顺序

本轮推荐顺序不再沿用旧文档的“谁文件不存在就先做谁”，而是按依赖关系推进。

5.1 第一组：先收口上下文前置页

1. P01 门店选择页
2. P18 堂食扫码确认页
3. P02 地址管理页

原因：

• 顾客进入点餐和结算前，必须先把 门店 / 场景 / 履约信息 这三个前置上下文稳定下来。
• 当前这三页虽然都已有最小实现，但都还没有达到冻结后的页面职责。

5.2 第二组：收口点餐与加购链路

1. T02 点餐页
2. C01 商品详情抽屉
3. C02 购物车抽屉

原因：

• 点餐页已经是当前仓库里最接近真实业务的主链路页面。
• 现在更值得做的是“对齐冻结规格”，而不是重新从零搭页。
• 商品详情抽屉和购物车抽屉已经接入点餐页，应该和 T02 一起收口，而不是分离推进。

5.3 第三组：收口结算与支付结果

1. P03 结算确认页
2. P04 支付成功页

原因：

• 当前 repo 已经有建单和模拟支付能力。
• 真正缺的是“页面职责表达”和“支付后承接”是否与冻结结论一致。

5.4 第四组：收口订单后链路

1. T03 订单页
2. P05 订单详情页

原因：

• 订单页和详情页已经有最小能力，适合在支付闭环收口后继续精修。
• 这一步的目标是让顾客能看懂、找得到、做得了下一步动作。

5.5 第五组：最后回补聚合页

1. T01 首页
2. T04 我的页

原因：

• 首页和我的页目前都已有入口骨架，但都还不是最终职责形态。
• 它们依赖前面几组页面的上下文、动作和可跳转目标，适合最后统一回补。

---

6. 逐项执行清单与验收标准

6.1 P01 门店选择页

• 当前状态：
  • 已有页面文件和最小切店能力。
  • 已能承接基础门店列表展示。
• 本轮必须补齐：
  • 门店搜索。
  • 按当前场景或门店 serviceTypes 过滤 / 标记可用性。
  • 最近使用门店或定位门店的结构占位。
  • 切店后的全局上下文刷新和回跳逻辑。
• 验收标准：
  • 切店后 首页 / 点餐页 / 结算页 上下文同步变化。
  • 当前场景不支持的门店不能被误选。
  • 页面具备加载态、空态、异常态。

6.2 P18 堂食扫码确认页

• 当前状态：
  • 已有最小桌号输入和保存能力。
  • 目前更像“桌号保存页”，还不是扫码确认页。
• 本轮必须补齐：
  • 扫码结果确认卡。
  • 桌台信息区和堂食规则说明区。
  • 确认后切换场景为 dine_in。
  • 确认后进入点餐页，不再只是保存后返回。
• 验收标准：
  • 有扫码参数时能正确承接。
  • 无扫码参数时有明确兜底路径。
  • 确认后点餐页进入堂食上下文。

6.3 P02 地址管理页

• 当前状态：
  • 已有最小地址表单。
  • 依赖 customerStore + fulfillmentStore 保存单地址信息。
• 本轮必须补齐：
  • 地址列表态。
  • 当前选中地址态。
  • 默认地址标记。
  • 新增 / 编辑入口占位。
  • 从结算页进入、选择后返回的链路。
• 验收标准：
  • 外卖场景可进入并带回选中地址。
  • 自提 / 堂食场景不误导进入地址选择。
  • 空地址时有明确引导。

6.4 T02 点餐页

• 当前状态：
  • 已有分类、菜单、场景切换、加购、抽屉联动等基础能力。
  • 是当前仓库最接近交易主链路完成态的页面。
• 本轮必须补齐：
  • 类目展示严格跟随当前渠道和场景。
  • 搜索区、活动摘要区、类目高亮与吸顶表达。
  • 简单商品直接加购。
  • 复杂商品进入 C01，不直接跳过选择过程。
  • 底部购物车栏与 C02 的联动收口。
• 验收标准：
  • 切换门店或场景后菜单和类目刷新正确。
  • 售罄商品不能误加购。
  • 页面结构与 docs/07-页面规格/02-Tab-点餐页.md 一致。

6.5 C01 商品详情抽屉

• 当前状态：
  • spec-popup 组件已存在并接入点餐页。
  • 已不是“未实现”状态。
• 本轮必须补齐：
  • 商品图、描述、标签、销量、价格表达。
  • 规格组、做法、加料、套餐组合选择。
  • 金额实时变化。
  • 售罄、禁选、默认选中规则。
  • 复杂商品加购写入 cartStore。
• 验收标准：
  • 从点餐页商品卡能稳定打开。
  • 选择项变化后金额即时刷新。
  • 关闭再打开时状态重置策略明确且一致。

6.6 C02 购物车抽屉

• 当前状态：
  • cart-drawer 组件已存在并接入点餐页。
  • 已具备最小购物车编辑基础。
• 本轮必须补齐：
  • 商品行编辑、数量增减、清空动作。
  • 优惠摘要或凑单提示区。
  • 空购物车联动关闭或空态提示。
  • 去结算动作与 P03 的承接。
• 验收标准：
  • 数量和金额变化实时同步。
  • 清空后底部栏和抽屉状态同步清零。
  • 无商品时不能继续进入结算。

6.7 P03 结算确认页

• 当前状态：
  • 已有金额试算、结算校验、建单、模拟支付。
  • 已具备最小闭环能力。
• 本轮必须补齐：
  • 外卖 / 自提 / 堂食三场景差异卡片。
  • 地址区 / 自提门店区 / 堂食桌台区。
  • 手动资产 与 自动优惠 分开展示。
  • 备注区和附加说明区。
  • 支付方式表达只先收口为 微信支付 / 余额支付。
• 验收标准：
  • 无商品不能提交。
  • 金额明细、优惠明细、应付金额逻辑一致。
  • 不把 积分抵扣 先写死进主结算流程。

6.8 P04 支付成功页

• 当前状态：
  • 已有最小结果页。
  • 已支持跳订单详情、订单列表、继续点餐。
• 本轮必须补齐：
  • 订单摘要区。
  • 场景差异信息区，如配送预计、自提提示、桌台信息。
  • 缺少订单上下文时的兜底回流。
  • 与 P03 的稳定跳转关系。
• 验收标准：
  • 结算成功后稳定进入。
  • 从结果页可继续进入详情、订单页或点餐页。
  • 直接打开时不会停留在无意义空白页。

6.9 T03 订单页

• 当前状态：
  • 已有最小订单列表和状态切换基础。
• 本轮必须补齐：
  • 顾客视角状态筛选。
  • 场景信息和核心动作区。
  • 去支付、查看详情、再来一单等动作承接。
  • 空态回流点餐页。
• 验收标准：
  • 订单状态表达是顾客语言，不是后台列名。
  • 各卡片 CTA 与详情页动作一致。
  • 不强行冻结 催单 / 骑手轨迹 / 取餐码。

6.10 P05 订单详情页

• 当前状态：
  • 已有最小详情页和基础状态展示。
• 本轮必须补齐：
  • 履约时间轴。
  • 商品清单和费用明细。
  • 基础信息区，如订单号、时间、支付方式、备注。
  • 按状态显示底部动作。
• 验收标准：
  • 未支付、履约中、完成、关闭等状态动作不混乱。
  • 未找到订单时有空态和回流。
  • 页面结构与 docs/07-页面规格/11-订单详情页.md 对齐。

6.11 T01 首页

• 当前状态：
  • 已有门店上下文、场景切换、部分业务展示骨架。
  • 当前仍残留较多“项目说明型”表达。
• 本轮必须补齐：
  • 按门店支持能力驱动的场景切换。
  • 动态活动区，而不是固定八宫格。
  • 推荐商品区、服务信息区、导流入口区。
  • 减少开发说明模块对主视觉的占用。
• 验收标准：
  • 首页首先服务交易导流，而不是展示开发说明。
  • 页面结构与 docs/07-页面规格/01-Tab-首页.md 一致。
  • 首页能稳定导流到点餐、订单、活动和服务页。

6.12 T04 我的页

• 当前状态：
  • 已有页面和占位模块。
  • 当前仍偏联调 / 演示页。
• 本轮必须补齐：
  • 用户头部卡。
  • 资产摘要区。
  • 订单快捷入口区。
  • 会员增长入口区。
  • 服务入口区和复购推荐区。
• 验收标准：
  • 我的页是聚合页，不把资产值写成唯一真源。
  • 不把不稳定数量字段写死成强依赖。
  • 页面结构与 docs/07-页面规格/04-Tab-我的页.md 一致。

---

7. 跨页面统一验收标准

只要进入本轮执行范围，每个页面 / 组件都至少满足以下统一标准。

7.1 状态标准

• 有默认态。
• 有加载态。
• 有空态。
• 有异常态。
• 有禁用态。

7.2 触控与交互标准

• 主点击区域不小于 44px。
• 异步按钮必须有 loading 或禁用反馈。
• 错误信息尽量贴近问题区域显示。
• 不允许通过隐藏规则让顾客猜下一步怎么做。

7.3 上下文一致性标准

以下上下文跨页必须一致：

• 当前门店
• 当前场景
• 购物车内容
• 当前地址或桌台信息
• 结算金额口径

7.4 文案标准

• 用顾客语言，不用商家后台语言。
• 用动作导向文案，不用系统字段名堆砌文案。
• 同一种状态在不同页面不要出现冲突叫法。

---

8. 当前这份文档的使用方式

如果现在继续推进正式小程序仓库，建议直接按下面节奏执行：

1. 先做 P01 + P18 + P02，把前置上下文补稳。
2. 再做 T02 + C01 + C02，把点餐和加购链路收口。
3. 再做 P03 + P04，把支付前后闭环收口。
4. 再做 T03 + P05，把订单后链路收口。
5. 最后回补 T01 + T04，把聚合页改成最终职责形态。

一句话结论：

当前正式仓库已经不是“很多页面还不存在”的阶段，而是“多数关键页面都已有最小实现，现在要按新冻结规格逐项收口”的阶段。