做本地生活服务的小程序，商户端往往是最容易被低估的模块。很多团队把精力砸在用户端界面，结果商家后台一塌糊涂——订单漏接、库存对不上、结算靠手工Excel。问题出在哪？不是功能少，是架构没撑住。

从单店到连锁，架构得扛得住

云县本地商户有个典型特征：起步是单店，半年内可能裂变到三五个点位。如果商户管理系统一开始就用单表存订单、用本地缓存扛并发，扩张时必然重构。我们在小程序定制项目里通常采用「商户-门店-角色」三级模型，权限粒度落到SKU级别，这样新增门店只是加一条记录，而不是改一套代码。

核心技术选型不是堆技术栈

后端用Node.js还是Java？数据库选MySQL还是PostgreSQL？这些争论意义不大。真正影响商户管理系统稳定性的是三件事：

• 订单状态机——必须用有限状态机管理，避免「已取消」被回调改成「已完成」这类脏数据
• 幂等设计——支付回调、库存扣减全部走唯一键约束，不依赖应用层判断
• 异步解耦——通知、对账、报表走消息队列，别堵在主流程里

云县掌中软件开发服务部在多个本地生活软件开发项目中验证过，这套组合能把商户端的日均故障率压到0.3%以下。

选型指南：别为用不上的功能买单

小微企业数字化最怕「功能过剩」。一个日订单50单的餐饮店，不需要分布式事务；一个社区便利店，不需要多级分账。选型时盯住三个指标：

1. 当前日均订单量×3，就是你要压测的峰值
2. 商户操作路径不超过3步，否则培训成本会吃掉利润
3. 是否支持图文设计素材直接同步到商品详情，减少重复上传

至于网站搭建和小程序定制的边界，我们的经验是：商户管理走小程序，数据看板走Web后台，两者共用一套API网关。这样商家在手机上接单，在电脑上看报表，体验不割裂。

未来两年，云县本地的商户管理系统会从「工具」变成「节点」——对接供应链、对接同城配送、对接金融结算。架构上预留好Webhook和开放接口，比现在多写一万行代码都值。