C端（消费者端）待办简报 · 给小齐

背景：b端（商户工作台）与 c端（消费者端）的边界刚理清。本文档是 c端需要承接的需求简报，b端（波波）不再碰 c端页面，交由小齐（v2 前端 / miniprogram-v2 负责人）接手。

整理时间：2026-09-23。本文档中的"错误示范"来自波波在 b端误建扫码页的踩坑，供 c端避坑。

一、三个端的边界（先对齐，避免再踩错）

铁律：B端是"商户自己干活的后台"，C端是"消费者用的前台"。任何消费者扫码看到的公开页都属于 C端，不要塞进 B端工作台。

二、C端要做的两个「线下扫码」场景

1. 扫码展销页（商户码牌页）

• 场景：商户在线下贴码（如 b.kailashi.cn/s/{merchantId} 或小程序太阳码），消费者扫码 → 看这家商户自己的商品/服务 → 自助下单。
• 本质：C端公开页（消费者免登录或游客态可见），不是 B端功能。
• 数据来源（最重要）：展示商户自己的商品，对应库表 service_items（按 merchant_id 维度的自营品，如房型/餐食/当地服务）。
• ❌ 严禁展示平台模板表 packages（那是平台级统一模板，且当前 prod 里全是 测试套餐001~008 这类 seed 数据）。
• ❌ 严禁把任何测试/seed 数据露给真实消费者。
• 当前状态（波波踩坑记录）：
• 后端 GET /api/miniapp/stalls/:merchantId 已建，但数据源错（拉了 packages 平台模板），需改为拉 service_items。
• 页面 StallShop.tsx 被误建在 b-workbench/ 前端里——需移植/重建到 C端，B端那版可作为参考但不要留在 B端。
• 后端数据源纠正波波会在 b端收尾时一并改，或 c端接手后直接改后端（端点已存在，只换 SQL 取数）。

2. 统一收费（消费者扫码付款）

• 场景：消费者扫商户「统一收款」码 → 付款（买单 / 统一结账）。同样是消费者扫码的 C端公开场景。
• 后端已有（商户侧）：B端 PaymentSettings（收款方式设置，按品类 online/offline，WIP-221/222/223）+ 后端「商家确认收款」端点（在 merchant_console.py）。
• C端缺口：消费者侧的扫码付款页/小程序页目前未建。需确认落在小程序还是同扫码展销页一样走公开 H5。
• 建议：先找波波/阿仁对齐已有「商家确认收款」端点请求/响应形状，再设计 c端付款流（下单 → 支付 → 商户确认收款 → 核销）。

三、数据纪律（c端 / b端共用）

1. 商户自己的数据：原则上商户在 B端自录，A端可代录。C端只负责展示商户已录入的数据，绝不自己造数据、不硬编码。
2. prod 库（生产库）现状预警：当前 kailash 生产库混有 seed/冒烟数据（测试套餐001~008、测试商户001~005）。上线前必须清理或隔离，绝不可作为真实内容露给消费者。
3. 展示数据可配置：凡 c端展示的商户信息/商品/文案，数据须来自后端接口，不由前端写死（与 A端纪律一致）。

四、给小齐的入手建议

1. 先定载体：扫码展销页 / 统一收费页，是放小程序（miniprogram-v2）还是公开 H5？这决定路由、登录态、码的生成方式。
2. 后端取数：/stalls/:id 的 packages → service_items 纠正，可等波波在 b端收尾时改，也可 c端直接接手改（端点已存在）。
3. 对齐收款闭环：统一收费消费者页前，先和波波/阿仁对清「商家确认收款」端点形状（请求字段、幂等、金额单位）。
4. 避坑：别把平台模板当商户商品、别把测试数据当真数据上线、别把 c端公开页塞进 b端。

五、波波在 b端会继续做什么（与 c端无关，仅同步）

• 修 /stalls/:id 后端取数为 service_items（顺手把误建的 B端 StallShop.tsx 也调整/下线，公开页移交 c端）。
• 商户工作台既有功能（核销、接单、账单、收款方式、评价回复、档案）的收尾与一致性。
• 补 b.kailashi.cn 之前缺失的 /api/ 反代（已修，整个 B端在该域名下已能拉真实数据）。