唐山多门店小程序怎么做？

你好，我是知码客，一个在唐山写代码的独立开发者。最近接了个活儿，客户在路北区和丰南区各有三家门店，做的是本地连锁餐饮，老板上来第一句话就是：“我不想再让店员每天手动改库存了。”这句话基本把多门店小程序的核心痛点说透了。

多门店小程序到底难在哪

很多唐山做小程序的同行聊起来，都觉得多门店就是“多开几个页面”。真上手就知道不是这么回事。单店小程序是线性的，用户进来、选商品、下单、支付，一条路走到底。多门店则是一张网：用户要先定位或选择门店，商品和库存要按门店隔离，价格和活动可能不一样，订单要落到对应门店，店员还得有各自的核销权限。

• 门店维度：地址、营业时间、电话、配送范围，每家一套
• 商品维度：同款商品在不同门店可能缺货，也可能价格不同
• 订单维度：订单必须归属门店，核销、退款、对账都按门店走
• 权限维度：店长只能看自己店的数据，老板看全局

这四层如果一开始没设计好，后面每加一家店都是灾难。我在给唐山本地客户做方案时，习惯先把门店模型定死，再谈页面。

数据模型：门店是一等公民

用微信小程序云开发做多门店，结构其实很清爽。核心是给每个集合都带上 storeId，让门店成为数据的第一维度，而不是事后补丁。

// 门店集合 stores
{
  _id: "store_lubei_01",
  name: "路北万达店",
  address: "唐山市路北区...",
  location: { latitude: 39.63, longitude: 118.18 },
  businessHours: "09:00-21:00",
  deliveryRange: 3000,
  status: 1
}

// 商品集合 products，按门店隔离库存
{
  _id: "p_1001",
  storeId: "store_lubei_01",
  name: "招牌套餐",
  price: 38,
  stock: 20
}

查询时永远带上 storeId 条件，云开发里就是一句 db.collection('products').where({ storeId })。别嫌啰嗦，这是后面所有功能的地基。

门店选择与定位的取舍

用户第一次进来，最自然的动作是“离我最近的门店”。小程序里用 wx.getLocation 拿经纬度，再和门店坐标算距离排序就行。但这里有个坑：用户拒绝授权定位怎么办？我的做法是给一个默认门店，同时在顶部放一个明显的切换入口，让用户手动选。唐山城区不大，用户对“万达”“远洋城”这些地标很熟，按商圈列门店比纯按距离更友好。

别把定位授权做成拦路虎。多一步强制授权，就多一批流失。

库存与订单的门店隔离

库存这块，多门店最容易出问题的是并发。两家店同时卖最后一份套餐，如果扣减逻辑写错，就会超卖。云开发里可以用数据库事务或者原子操作 inc 来控制：

const _ = db.command
await db.collection('products')
  .where({ _id: productId, storeId, stock: _.gt(0) })
  .update({ data: { stock: _.inc(-1) } })

订单表里一定存 storeId 和 storeName 快照。门店改名了，历史订单也要能对上账，这是给财务看的，不是给程序员看的。

权限：店长和老板看到的不一样

多门店后台最忌讳“一个账号看所有”。我用云开发的数据库权限配合自定义安全规则，给每个店员绑定 storeId，店长登录后只能查自己店的订单和核销记录。老板账号单独一个角色，能看汇总。这样客户把店交给店长也放心，不用天天盯着。

唐山本地场景的一些体会

给唐山客户做项目，我发现几个特点。一是连锁门店集中在几个商圈，门店数量不会特别多，但每家店的运营节奏差异大，所以后台的灵活性比功能数量更重要。二是老板普遍关心“能不能自己改”，所以我会把门店信息、营业时间、临时歇业这些做成可视化配置，不用每次找我改代码。三是本地客户很看重响应速度，唐山app开发和小程序开发的圈子不大，口碑传得快，做完一个项目，隔壁店的老板可能就找过来了。

前阵子还有个做建材的客户问我，多门店小程序能不能管不同仓库的货。其实逻辑是通的，把“门店”换成“仓库”，storeId 换成 warehouseId，一套模型能复用。这也是我建议一开始就把门店抽象成独立实体的原因——业务会变，模型别写死。

写在最后

多门店小程序不是功能堆砌，而是数据模型的功夫。门店、商品、订单、权限四层理清楚，后面加店就是加一条记录的事。我是知码客，在唐山做小程序和 APP 开发，习惯把复杂的东西拆成能维护的模块。如果你也在琢磨多门店的事，欢迎聊聊，说不定能少踩几个坑。