我在郑州一线商圈做扫码买单小程序时，最先感受到的不是功能点，而是商户的操作痛点：核销慢、对账难、数据零散。于是项目目标很直接——做到一键核销、实时统计，减少人工干预。实践让我意识到，需求看起来简单，但并非只是一行按钮能解决的问题。

      前端选择了微信小程序原生栈加 Vant Weapp 做组件，支付与扫码两端都用微信开放能力。用户侧走的是 JSAPI 支付流程，商户侧我们提供“扫码核销”界面：扫码后立即调用后端核销接口并展示成功/失败原因。遇到的真实问题是网络抖动导致重复点核销，这里用幂等 token +短期锁（Redis SETNX + 5s TTL）把重复请求过滤掉，效果比前期在前端禁用按钮更可靠。

      后端我选用 Go（Gin）作为主服务，MySQL 做事务性订单存储，Redis 做缓存与分布式锁，Kafka 负责事件总线，ClickHouse 做统计 OLAP。一个关键实现是“一键核销”的原子性：扫码带上 voucher_id 与 HMAC 签名，服务端用 Redis Lua 脚本做 check-and-set——检查未核销且签名验证通过后同时写入订单状态并发出事件。这个组合避免了数据库孤岛与并发双核销问题，实际上现场问题主要出在超时重试上，调整 Lua 脚本与超时时间后稳定性显著提升。

      安全和审计方面，我坚持两点：密钥不在代码库、审计事件不可篡改。支付证书与 HMAC 秘钥放入云 KMS（我用腾讯云 KMS），调用时通过短期凭证解密。所有核销动作同时写入不可变日志（ES + 索引策略），便于追溯。遇到疑难交易时，分布式追踪（Jaeger）和 Redis slowlog 常常能透露线索——不要只看应用日志，网络层和 DB 层的痕迹同样关键。

      上线与运维同样重要。CI/CD 用 GitLab CI 打包镜像，Kubernetes + Helm 部署，灰度发布与健康检查是必须。压测时我们发现数据库成为瓶颈，解决路径是读写分离、垂直切表与按商户分区。一个经验：不要在没有监控的数据上盲目扩容。Prometheus 指标和 Grafana 仪表盘让我在问题爆发前察觉慢查询与连接数飙升。

      总结几条我会坚持的实操建议：一，先把核销流程做成幂等、可回溯的事件；二，统计体系尽早用专用 OLAP（比如 ClickHouse）设计；三，遇到并发问题先用 Redis 原子脚本验证思路；四，生产环境要有完整的追踪与告警。未来可以引入更轻量的 serverless 对热点函数做弹性扩缩，但落地时仍需按场景权衡，别急于做过度设计。