最开始不是从理想出发，而是从抱怨开始。郑州几所高校的师生反映，外卖常常因为校内道路封闭、宿舍取餐点分散和上下课流水式高峰而延迟。我们接手的第一个任务，就是把“专属配送调度”做好：既要保证晚自习后半小时内送达，又要避免骑手在校园里无效绕行。实践证明，需求看起来简单，技术细节却藏在边界条件里。

      架构上，我选择把定位与调度解耦。地图与路况用高德/腾讯双源裁决，路径规划采用开源的OSRM做二次校准，地理关系存入PostGIS，分区索引采用H3网格（分辨率7~9之间权衡）。为了保证实时性，候选骑手列表用Redis的有序集合缓存，消息总线选Kafka以承载峰值流量。这个组合不是硬性公式，而是基于延迟目标（P95 < 200ms）和成本预算的折衷。

      开发时我反复碰到移动端定位抖动问题：宿舍楼群导致GPS漂移，iOS后台定位被限制。解决办法是客户端做卡尔曼滤波与踏频检测（基于速度阈值），并在Wi‑Fi可用时补偿位置。服务器端对短期位置异常进行退订合并，避免把“瞬时离开”视为可配送候选，这一点在高峰时段能显著降低错分率。

      调度算法不是纯数学题，更多是工程权衡。模型上把问题看作带时间窗的Pickup‑and‑Delivery；求解采用两阶段：先用快速贪心按最近增量成本分配（考虑电梯等待、校门通行时间窗），再用局部搜索（2‑opt、relocate）做短时优化。遇到极端负载时，触发降级策略——按教学楼优先等级分区分发，确保教职工订单SLA。这个组合比纯粹的最小费用最大流在工程上更可控，也方便回滚。

      排查时我经常依赖几样工具：pprof和flamegraph定位调度函数的长尾；EXPLAIN ANALYZE找出PostGIS扫描瓶颈，避免对大量候选做ST_Distance；用Prometheus指标监控Redis命中率与Kafka积压，设置报警阈值。一次事故让我学到：把空间索引级别参数暴露为运行时可调配置，比频繁改代码更高效。

      实践带来一些不那么浪漫的判断：短期内投入到工程可观的地方，是稳定的定位流和低延迟的候选筛选。模型可以逐步复杂，但基础数据一定要可靠。下一步我倾向于在室内取餐点引入蓝牙Beacon校准，并做小规模A/B测试验证更细粒度的分区策略。技术展望是务实的：先把延迟和正确率稳住，再谈更复杂的预测。