# 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`，把聚合页改成最终职责形态。 一句话结论： 当前正式仓库已经不是“很多页面还不存在”的阶段，而是“多数关键页面都已有最小实现，现在要按新冻结规格逐项收口”的阶段。