多门店小程序：别急着写代码

上个月接了个咨询，做连锁烘焙的，六家店，想上多门店小程序。老板开口就问：“多少钱？多久能上线？”我没直接报价，先问了他一句：你现在六家店，库存是各管各的，还是总部统一调？他愣了两秒，说“这个……得问问店长”。

这就是多门店小程序最容易踩的坑——很多人以为多门店就是“加个门店切换按钮”，实际上切换按钮只是冰山露出水面的那一角。

多门店小程序，难的不是门店列表

我做过几个多门店项目，也帮人收拾过烂摊子。真正花时间的部分，基本都在下面这几件事上：

• 数据归属：商品是总部统一维护，还是各店能自己改价格？改完之后订单算谁的？
• 库存与履约：线上下单，是就近门店发货，还是统一仓发？到店自提的话，哪个店核销？
• 权限体系：店长只能看自己店的数据，区域经理能看一片，总部看全部。这套角色不设计好，后面加一个店就得改一次代码。
• 结算：钱进谁的账户？总部代收再分账，还是各店独立收款？这块涉及支付资质，不是纯技术问题。

这四件事里，任何一件没想清楚，写出来的多门店小程序都是半成品。我见过最典型的返工，是上线后老板说“我要每个店单独搞活动”，结果当初按单店逻辑写的优惠券表，全部推倒重来。

架构上我的两个建议

一、门店 ID 从第一天就贯穿到底

不管你现在是一家店还是十家店，数据库设计时就把 store_id 带上。商品、订单、会员、优惠券、员工，全部挂门店维度。哪怕初期只有一家店，store_id 固定填 1 也行。这个成本几乎为零，但能省掉后面一次大迁移。

// 订单表核心字段示例（云开发）
{
  _id: "order_xxx",
  storeId: "s_001",      // 归属门店，必填
  userId: "u_123",
  items: [...],
  amount: 58.00,
  status: "paid",
  createdAt: Date.now()
}

二、把“门店”当成配置，而不是代码

门店的营业时间、配送范围、联系电话、甚至是否支持自提，这些都应该存在数据库里，由后台配置。别写死在代码里，不然开一家新店就要发一次版，审核还得等。用云开发的集合存门店配置，小程序端启动时拉一次缓存，是最省事的做法。

关于成本和周期的实话

多门店小程序的开发成本，比单店版本通常高 30% 到 50%，主要贵在权限和结算逻辑上。如果只是“展示各店地址 + 就近导航 + 统一商城”，那确实不贵；但凡涉及分账、独立库存、门店级营销，预算就得往上走。周期上，功能收敛清楚的话，四周到六周能出可用版本，前提是需求别在开发中途反复变。

我常跟客户说：多门店小程序的钱，一半花在写代码，一半花在帮你把业务规则捋顺。后者省不得。

给准备动手的独立开发者

如果你是自己接活做多门店项目，接单前务必让甲方把“门店之间哪些共享、哪些独立”列成表，签字确认。这张表比任何原型图都值钱。另外，多门店小程序上线后，门店数量往往还会涨，所以后台的门店管理模块要做得能自助增删，别让自己变成甲方的运维。

说到底，多门店小程序不是技术炫技，是把连锁经营的规则翻译成代码。规则清楚了，代码反而简单。