邯郸门店小程序：从0到1的实战复盘

我是知码客，一个在邯郸做小程序和 APP 开发的独立开发者。这几年接得最多的需求，就是本地门店想做一个小程序。餐饮店、汽修厂、母婴店、健身房，老板们的诉求都很朴素：让老客户下单方便点，让新客户能搜到我们。这篇文章不讲虚的，就把我最近在邯郸做的一个门店小程序项目拆开聊聊，从需求梳理到上线踩过的坑，都是真金白银换来的经验。

先搞清楚：门店小程序到底解决什么问题

很多老板一上来就说“我要做个小程序”，但你问他具体要什么功能，往往答不上来。我的习惯是先问三个问题：

• 你的客户主要从哪来？是路过进店，还是朋友圈、微信群？
• 你希望客户在小程序里完成什么动作？点单、预约、领券，还是查会员余额？
• 店里谁负责维护？是老板自己，还是有专门的店员？

这三个问题决定了技术方案。比如邯郸丛台区一家做卤味熟食的店，客户基本是周边三公里的小区居民，那核心就是“线上下单 + 到店自提 + 满减券”，不需要复杂的会员体系；而复兴区一家汽修厂，客户是预约保养的车主，重点就变成“服务项目展示 + 预约时段 + 到店提醒”。方向错了，功能做得再多也是浪费钱。

技术选型：门店场景别过度设计

门店小程序的体量通常不大，页面数量在 10 到 20 个之间，我一般直接用微信原生开发配合云开发，理由很实在：

• 不用单独买服务器、配域名、搞备案，云开发开箱即用，对小店老板来说成本可控；
• 数据库、云函数、存储都在一个控制台里，后期改需求响应快；
• 微信支付、订阅消息这些能力接入路径成熟，踩坑少。

当然也有例外。如果门店后面打算做多端（比如同时上抖音小程序、支付宝小程序），或者要和现有的收银系统、进销存打通，那就得用 uni-app 这类跨端框架，或者干脆做前后端分离。我在邯郸做过一个连锁烘焙店的项目，他们有三家门店、共用一套库存，这种就必须上自建后端，云开发的免费额度撑不住。

几个容易翻车的细节

1. 门店定位和配送范围

门店小程序几乎都要用到位置能力。这里有个坑：wx.getLocation 需要在后台申请接口权限，而且要写清楚使用场景，否则审核会被打回。我的做法是在“到店自提”页明确展示门店地址和导航按钮，在“同城配送”页用经纬度算距离，超过设定范围就提示“超出配送范围，建议到店自提”。邯郸城区不大，但峰峰、武安这些周边区县的客户如果下单，配送成本会很高，提前用距离判断能省掉很多售后扯皮。

2. 支付和订单状态

微信支付的回调一定要做幂等处理，我见过有开发者因为回调重复触发，导致订单被重复标记为已支付。简单做法是在云函数里先查订单状态，已处理过就直接返回成功。另外订单状态机要设计清楚：待支付、已支付、待自提、已完成、已取消，每个状态对应哪些操作，最好在需求阶段就和老板对一遍，别等做完再改。

3. 后台管理要“傻瓜化”

这是最容易被忽视的一点。门店小程序的用户不只是顾客，还有店员。商品上下架、改价格、看订单，如果后台做得复杂，店员根本不会用，最后又回到微信里手动记账。我的经验是：后台首页只放“今日订单”“待处理”“商品管理”三个入口，能点按钮解决的绝不让人填表单。给邯郸一家社区超市做的时候，我甚至把“缺货下架”做成了列表页的一键开关，老板娘用了两周就上手了。

上线之后才是开始

小程序提交审核前，记得把体验版发给老板和店员真机走一遍完整流程，尤其是支付。上线后也别急着推广，先观察一周的访问数据：哪些页面跳出率高、哪个环节下单转化低，再针对性优化。门店小程序的流量本来就有限，把已有的客户服务好，比盲目拉新更重要。

如果你也在邯郸，正琢磨着给自家门店做个小程序，欢迎找知码客聊聊。我不一定接所有需求，但可以帮你把方案想清楚，少走弯路。