做这个郑州生鲜配送小程序时，最先碰到的不是界面，而是“生鲜新鲜”这个行业硬指标：保质期短、订单峰值集中、频繁退换货。我们一开始用简单的库存表，结果双十一式订单浪潮里频繁超卖；那次教训促使我把库存一致性、冷链追踪和配送调度做成了工程问题来解决，而不是业务描述。

      技术栈的选择不是炫技，而是权衡：前端采用微信原生小程序 + Vant Weapp 做组件，构建阶段用 miniprogram-ci 接入 CI；后端用 Node.js（NestJS）做微服务框架，MySQL 做关系存储，Redis 做缓存与幂等控制，消息中间件选 RabbitMQ 做异步削峰。实操中发现，使用 Redis Lua 脚本做原子性减库存，比单纯乐观锁少了很多竞态调试；备选方案是将关键减库存接口迁移为事务型服务并在数据库层加 version 字段，再配合幂等 key 来避免重复扣减。

      配送和定位的实现细节很重要。仓配匹配用 Redis GEO 索引快速筛选最近仓库，随后交给独立的路线规划微服务（用 Google OR-Tools 做 CVRP）来考虑冷藏车容量与时窗约束。实践中我发现，实时性与最优性常常冲突：当车辆数目与订单量都在变动时，启发式算法比严格求解能保证延迟，便于在 5 秒内返回可执行路线。

      冷链监控不是花架子，而是由边缘到云端的链路。我们通过 NB-IoT 模组上报温湿度数据，接入 EMQX 的 MQTT Broker，再写入 InfluxDB 做时序存储；Grafana 负责可视化与阈值告警。真实场景里，通信丢包是常态，做了本地缓存与重试策略之后，异常率从 8% 降到 1% 多；这让我意识到设备端的鲁棒性和后端的幂等接收同等重要。

      性能与运维不是一次性工作。用 Kubernetes 部署微服务，镜像通过 GitHub Actions 构建并推送到私有仓库；Prometheus + Grafana + Alertmanager 链路覆盖 API 延迟、队列积压和温湿度异常。一个小技巧：在流量高峰前，把热点商品缓存预热并用短 TTL 的二级缓存策略，缓存穿透问题明显缓解，DB 压力峰值也平滑了。

      最后一点经验：不要把所有逻辑都塞在小程序端。把支付（微信支付 V3）、订单幂等、物流调度放在受控后端；小程序负责体验与网络校验。未来可以考虑把部分调度下沉到边缘节点、用更细粒度的时序算法优化车队利用率。实践证明：工程化、可观测和适度的简化，比追求理论最优更能保鲜客户体验。