把到店、下单、预约、查询这些高频动作搬到手机上。先确认业务闭环，再决定用小程序、H5 还是两者并行，避免为了“有个小程序”而上线一个没人用的空壳。
小程序的价值在于缩短一次业务动作的路径。我们先确认用户从哪进来、要完成什么、完成后数据回到哪里，再反推需要哪些页面与接口。常见闭环包括：浏览商品并到店自提、预约服务并到店核销、提交报修并跟踪进度、查询会员余额与订单。
商品与订单、会员与积分、预约与核销、内容发布、消息通知、支付，这几块是最常被使用的。支付需要客户自有商户号并完成相应开通流程；消息通知受平台模板限制，触发条件要在需求阶段就写清楚。
主包控制在 2MB 以内，超出部分用分包加载，首屏只加载必要资源。提交审核前准备类目资质、隐私政策与用户授权说明，避免因材料不全反复退回。上线后保留版本更新与数据看板，便于按周观察使用情况。
| 开发平台 | 微信小程序为主，可扩展支付宝小程序与移动端 H5 |
|---|---|
| 技术方案 | 原生开发或跨端框架，按后续多端需求选择 |
| 主包体积 | ≤2MB，超出部分分包加载 |
| 账号体系 | 手机号授权或既有会员体系对接，支持绑定与解绑 |
| 支付能力 | 需客户提供已开通的商户号，按平台规则接入 |
| 接口对接 | 与 ERP / CRM / 订单系统通过接口同步，字段映射表先行 |
| 合规材料 | 类目资质、隐私政策、用户授权说明、客服配置 |
| 交付形式 | 前后端源码、测试账号、部署与审核材料 |
3–6 周，含需求确认、开发、联调、审核提审。周期从需求确认之日起算，客户方评审与素材准备时间另计。
不一定。到店支付、线下核销、纯展示与预约都不需要支付能力。只有在线上收款时才需要接入支付，并需要客户自有商户号完成开通。
两者分工不同：公众号适合内容触达与推送，小程序适合完成操作。常见做法是公众号负责通知与内容，小程序负责下单、预约与查询。
可以。代码与数据库结构按模块组织，新增模块不影响既有页面。建议按季度集中排一次迭代，避免频繁小改导致审核次数过多。
