郑州单商户门店系统开发 轻量化助力中小商户转型

      开始于一个真实案子：在郑州为一家单门店早餐铺做轻量化门店系统，我先从最痛的点切入——网络不稳定、支付异步、库存要实时，却又不能依赖高昂运维。

      选栈时我偏向极简：后端用 Go + Gin，数据库优先 SQLite（WAL 模式），前端用 Vue 3 + Vite 做 PWA，离线数据用 Dexie.js（IndexedDB 封装）。这是经验导向的折中：启动快、资源占用低，单门店场景足够。

      开发里遇到的第一个坑，是并发写入 SQLite 导致的锁等待。测试环境看不出问题，真实门店高频刷单就崩了。解决方式是把写操作集中到单一写协程，读走并发通道；必要时把统计类写入批量化、异步落盘。这样虽然牺牲了些实时性，但稳定性换得明显。

      支付接入要细致：微信/支付宝回调可能重复、延迟，必须实现幂等处理。我用请求唯一 id +数据库幂等表记录通知状态，外加主动对账任务（每日与第三方流水比对）。证书、签名、时间戳都做成可热更配置，避免运维中断。

      离线优先策略带来缓存一致性问题：曾因 Service Worker 缓存策略导致库存显示延迟。经验是把 UI 走“stale-while-revalidate”，关键接口开启短时强制过期，并用 Background Sync 在恢复网络后回传本地变更。实现并发冲突时，采用乐观锁+版本号合并，简单且可追溯。

      工具链不复杂但必须到位：CI 用 GitHub Actions，镜像用 BuildKit 精简层，部署用 Docker Compose 在小 VPS 上运行。监控靠 node-exporter + Prometheus，日志走 Loki，错误跟踪用 Sentry。我更倾向轻运维堆栈，便于门店自行重启与回滚。

      项目收尾时的教训是：不要追求全功能一次性上线。先把核心业务做稳，留接口与迁移策略。未来可以考虑把 SQLite 替换为分布式轻量时序或云 DB，用增量同步替代批量导出。技术不是万能，但正确的工程权衡能让单店系统长期可用。