邯郸小程序开发：一个本地案例复盘

前阵子有个邯郸本地的客户找到我，说想做个小程序，聊了两次就定了。项目不大，但挺典型，适合拿出来讲讲。写这篇不是为了吹技术，而是想把一个真实的小程序开发案例拆开，给邯郸这边想做小程序、做 app 的朋友一点参考。

客户背景：一家本地连锁烘焙店

客户在丛台区和邯山区各有一家门店，主要卖面包、蛋糕和现烤点心。之前一直靠微信群接单，每天下午在群里发图片，客户私聊报单，老板手动记在本子上。问题很明显：

• 订单容易漏，尤其是节假日，群里消息一刷就找不到了；
• 客户问价格、问口味，店员要重复回答几十遍；
• 没有会员体系，老客户复购全靠人情；
• 两家店库存不同步，经常出现“这边有那边没有”的尴尬。

老板的原话是：“我就想有个自己的小程序，客户点进去能看能买，别老在群里翻。”需求很朴素，也很真实。

方案设计：不堆功能，先解决核心问题

很多邯郸做小程序的朋友一上来就问“能不能加直播、能不能加拼团”，我的建议是先别急。这个案例里，我只做了四块：

1. 商品与门店切换

首页顶部放门店切换，用户选丛台店或邯山店，商品列表和库存跟着变。这个逻辑不复杂，但能直接解决两家店库存不同步的问题。

2. 在线下单与到店自提

烘焙类目有个特点：配送半径短、时效要求高。所以第一版没做外卖配送，只做到店自提，下单时选时间段，店员按时间段备货。少一个配送模块，开发成本降了不少，上线也快。

3. 会员储值与优惠券

用微信支付自带的商家券能力，加上简单的储值余额。老客户充值送券，复购率肉眼可见地涨了。这块是老板最满意的，因为以前全靠嘴说“下次给你便宜点”，现在系统自动记。

4. 后台订单管理

店员用手机就能看订单、改状态、核销自提码。没做复杂的 ERP，够用就行。

技术选型：云开发省事

这个项目我用的是微信小程序原生 + 云开发。原因很实在：客户预算有限，不想单独买服务器、配域名、搞备案。云开发的数据库、云函数、存储基本能覆盖需求，后期维护也简单。

// 下单核心逻辑（简化版）
const db = wx.cloud.database()

exports.main = async (event) => {
  const { openid, items, storeId, pickupTime } = event
  const total = items.reduce((sum, i) => sum + i.price * i.count, 0)

  // 扣库存
  for (const item of items) {
    await db.collection('products')
      .where({ _id: item.id, storeId })
      .update({ data: { stock: db.command.inc(-item.count) } })
  }

  // 写订单
  const order = await db.collection('orders').add({
    data: {
      openid,
      items,
      total,
      storeId,
      pickupTime,
      status: 'pending',
      createdAt: db.serverDate()
    }
  })

  return { orderId: order._id, total }
}

当然，云开发也有坑，比如并发扣库存要做幂等、事务要小心。这个案例里订单量不大，我在云函数里加了简单的库存校验和重复提交判断，够用了。

上线后的真实反馈

小程序上线大概三周，老板给我发了条消息，说周末自提订单比之前群里接单多了差不多一倍，漏单基本没有了。这个数据不大，但对一家两家店的小生意来说，是实打实的改善。

更有意思的是，有个老客户在评价里写“终于不用在群里喊了”。这句话我觉得比任何技术指标都有价值。

给邯郸本地朋友的几点建议

• 先想清楚解决什么问题。小程序不是万能药，功能越多越难维护。像这个烘焙店，核心就是下单和会员，别的都可以后放。
• 预算有限就用云开发。省掉服务器和备案的麻烦，前期成本低，适合本地小商家试水。
• 别忽视后台。很多案例失败不是因为用户端不好看，而是店员不会用、不想用。后台越简单越好。
• 找本地团队沟通成本低。我在邯郸做小程序开发这些年，发现面对面聊一次，比线上来回发十天需求文档都管用。

我是知码客，专注小程序和 APP 开发。这个案例不算惊艳，但它真实、可复制。如果你也在邯郸，正琢磨着做个小程序把生意理顺，欢迎聊聊，说不定你的店就是下一个案例。