第一次接到郑州一家百平连锁店的点餐系统改造需求时，痛点很直观：高峰期下单延迟、门店与总部库存不同步、收银机断网就寸步难行。那段时间我反复问自己：技术能否把线上下单和线下门店体验无缝衔接，而不是做一堆看起来漂亮但不能抗压的接口？

      架构层面，我倾向于用 Go 做核心订单服务，gRPC 作为服务间协议，PostgreSQL 存事务数据，Kafka 做异步流水与回放。为什么这样组合？经验告诉我，高并发写入要靠分区化的消息系统来缓冲，Kafka 的可回放特性在对账和补单时极其实用；而 gRPC 能保证库存扣减等关键路径的低延迟。实践中要注意连接池、prepare statement 重用以及事务边界，哪怕是小细节也会影响高峰期的延迟曲线。

      前端与店内设备交互，我选择在门店局域网部署 EMQX（MQTT）做实时线路，厨房大屏用 WebSocket 作为备选。实际开发里我遇到过路由器对 WebSocket 的断连问题，换为 MQTT+持久会话后稳定很多。打印机采用 ESC/POS over TCP，调试时常常靠 Wireshark 抓包确认字节流，别低估字符编码与换行符差异带来的重打单问题。

      离线同步是核心难题。我用 SQLite 做本地写入缓冲，维护操作序列号与幂等键，后台通过增量日志（event sourcing 风格）做重放与冲突合并。冲突策略尽量简单：订单不可逆，菜品库存以中央库存为准，门店库存做弱一致性提示。这么做并非完美，但在我多次线上恢复中证明能把因断网导致的对账差错降到可接受范围。

      支付与对账环节必须严苛。接入支付宝/微信时实现幂等回调、签名校验和异步重试，实践中我给 webhook 加了幂等日志表和 1、4、16 秒指数退避逻辑；对账界面自动标注未决交易，人工介入时能快速定位原始 Kafka 消息并回放。这些细节初看繁琐，但能避免夜间运营哭诉。

      运维和排查工具是我常说的隐形功能：Prometheus+Grafana 指标，Jaeger 分布式追踪，ELK 做日志聚合；本地问题时用 adb logcat、tcpdump、Charles 来还原用户环境。压测阶段用 k6 模拟峰值场景，并结合 chaos 工具做断网与延迟注入，往往能提前暴露最脆弱的环节。

      我的建议不复杂：优先把可观测性、幂等与离线策略做牢，工具选型以“可回放”“本地可恢复”优先。做工程时少些绝对论，多些验证；版本迭代里先把关键路径做得可测、可回放，再去追求优雅。未来可以逐步引入边缘计算与更细粒度的事件一致性，但那一步，最好在你能复盘每一次异常之后再走。