上一个项目是为郑州数十家单商户门店做系统落地，需求从收银、库存到外卖对接一条龙。客户痛点很直接：网络一断单就乱，打印机编码随机乱码，营业高峰时库存超卖。于是我们把设计从一开始就往“离线优先+可恢复”倾斜，不盲目追求微服务，而是用清晰的边界和可观察性来换取稳定性。

      技术栈上我更倾向于实用：后端用 Go（Gin + GORM），主数据库 PostgreSQL，边缘设备用 SQLite 做本地事务，Redis 做缓存与分布式锁，RabbitMQ 处理打印、对账等异步任务。前端用 Vue 3 + TypeScript，桌面收银以 Electron 打包，方便串口驱动与打印机交互。选择这些工具时我考虑到的是可部署门槛，而不是潮流。

      实现离线同步时遇到的关键点很实际：如何保证本地提交后不丢单？我们采用变更日志（change log）+乐观并发控制，边缘设备先写 SQLite WAL，再把变更以 protobuf 压缩通过 gRPC/HTTP2 上报主库。冲突合并不是神话，通常靠版本号和最小可行回退策略解决，复杂合并只在后台人工介入。

      硬件对接比想象复杂。热敏打印机常见的乱码问题，多半是编码与控制指令不匹配——GBK/UTF-8、ESC/POS 指令集、串口波特率、USB 转串口驱动。实践里我用过 iconv 做编码转换，设定严谨的重试与幂等策略；还在 Electron 侧维护打印队列，避免高并发下丢单。

      性能调优来自血的教训。某次促销导致订单峰值，数据库慢查询暴露无遗。解决流程是：抓慢查询—EXPLAIN ANALYZE—增加复合索引—重写 JOIN 为预聚合。缓存失效问题用版本号而非时间驱动失效，Redis key 带版本号便于原子替换，减少脏读。

      运维与监控不可省。Prometheus + Grafana 用于指标，Jaeger 做分布式跟踪，Sentry 捕捉异常。对接支付回调时，幂等令牌、回调重试与对账任务同样重要。调试网络问题我常用 tcpdump、Wireshark，定位回调超时或证书链问题，比盲目改代码更有效。

      最后给出几条实操建议：一是把离线用例写进 CI；二是把硬件驱动作为独立模块，便于替换；三是采用出库（outbox）模式保障异步消息可靠投递。展望并非空谈，随着边缘设备能力提升，增量同步与更轻量的容器编排会更可行，但落地时请以稳定为先。