在参与郑州外卖点餐APP功能迭代时，我最先感受到的是商户对精准推荐和核销效率的双重诉求：客流高峰错单多、平台补贴浪费严重。于是把目标定成两件事——把推荐从“泛推”变成“高转化小流量”，把核销从“人工确认”变成“可追溯、低延迟”的闭环。

      技术实现上我走了两阶段检索+排序的路线。离线用LightGBM做CTR预估，特征工程侧重实时上下文：用户最近3次到店、商户近7日售罄率、促销叠加位次。这些特征写入Feast或Redis流，保证秒级可用。线上候选检索用商品/商户的语义嵌入（Transformer蒸馏到小型网络），通过FAISS HNSW实现近似最近邻检索，调参时重点看efConstruction与efSearch对内存与召回的权衡——这是常被忽视的工程量。

      排序层同时考虑曝光平衡与新店扶持，引入基于概率的多臂老虎机策略用于探索-利用折中。落地时遇到的实际问题不少：冷启动、特征泄露、模型分布漂移。解决办法是增加实时特征管道（Kafka->Flink），并在线上做分层校准（isotonic回归或温度缩放），避免线上推断概率失真。

      订单核销模块我更注重幂等与并发控制。基于Redis的SETNX实现扫码先锁定，再通过数据库乐观锁（version字段）完成状态变更；重复扫码返回幂等响应，避免重复扣减库存或二次退款。为防篡改，二维码采用HMAC签名并设短TTL，扫码请求走gRPC到商户侧网关，出现网络抖动时采用事务补偿与消息重试（Kafka+Dead Letter）。

      监控与运维同样关键。用Prometheus/Grafana监控延时分布、ClickHouse做后端召回与转化归因，配套日志链路用Jaeger做追踪，定位从扫码到核销的微秒级瓶颈。实操教训是：先把可观测性做好，再去优化模型，否则常常在看不见的地方打转。

      我的主观判断是，这类系统更像“工程+统计”的组合，不太可能一次性做完。短期优先保证稳定的实时特征与幂等核销逻辑；中期引入小型在线学习与量化推理（ONNX/INT8）以降低延时；长期考虑模型监控与闭环自动化。若要落地，建议先做小范围灰度和端到端指标跟踪。