美团 Java / 后端怎么准备
美团后端题常带时间窗：出餐、接单、送达、取消。系统要在高峰仍能给出可解释的状态，而不是只追求吞吐。
五题覆盖超时状态机、高峰削峰、取消补偿、围栏校验和协作。用你做过的调度或订单系统来答。
美团怎么面Java后端
- 项目深挖喜欢问「高峰晚高峰你怎么撑」。
- 设计题会加地图和超时，不要答成纯电商下单。
- 准备好取消、改址、联系不上骑手这些脏流程。
面试阶段与知识点
第一批不把每个阶段拆成独立 URL，避免程序化重复页。阶段对应下面的题，练完再用模拟面试串起来。
- 履约状态机：超时和取消比下单更难。
- 排队与削峰：线程池和消息堆积。
- 地理与围栏：脏数据和误判。
- 高峰值班：运力和用户体验的取舍。
值得开口练的题
每题给考察点、思路、结构化参考答案和追问。参考答案用来组织语言，面试时必须换成你自己的项目事实。
骑手超时未取餐，订单状态怎么走才不会把商家和用户卡死？
考察点
- 超时事件
- 多方通知
- 人工介入
回答思路
画出商家、用户、骑手三方状态机，任何一方超时都要有明确出口，避免页面卡死。
结构化参考答案
- 取餐超时先对骑手催办并允许改派，而不是立刻关单把商家和用户都卡在中间态。
- 每次状态变迁写入事件流，多端页面读同一事件源，避免各方各显示各的版本。
- 用户侧给可理解文案和取消入口，后台保留责任标记用于结算和客服追溯。
- 改派失败进入人工调度队列，禁止无限自动循环改派消耗运力和系统资源。
面试官可能追问
- 改派是否要重新计算预计送达？
- 商家已出餐但骑手取不到怎么办？
- 超时阈值全市一刀切行不行？
午高峰下单接口开始排队，线程池打满你怎么办？
考察点
- 拒绝策略
- 业务排队
- 用户感知
回答思路
区分线程池拒绝和业务排队；本地生活里「稍等片刻」往往好过立刻失败，但要可观测。
结构化参考答案
- 关键下单接口使用独立线程池，避免被导出、报表等低优先级任务拖死核心链路。
- 线程池满时走业务排队：返回排队号和预计等待，而不是把 RejectedExecution 抛到 App。
- 非核心写入链路可降级或异步，读请求可走短 TTL 缓存减轻数据库压力。
- 持续观察排队深度和处理延迟，超过阈值时停入口或限流，优先保护履约侧资源。
面试官可能追问
- AbortPolicy 和 CallerRuns 在这里怎么选？
- 排队过久谁来取消？
- 如何避免排队本身成为新瓶颈？
用户在骑手已取餐后取消，你怎么补偿？
考察点
- 责任划分
- 费用
- 状态不可逆点
回答思路
先定义不可逆点：骑手取餐后取消不再是简单关单，要按责任、费用和状态机处理。
结构化参考答案
- 取餐后取消走协商或客服流程，系统记录责任方和取消原因，不能一键静默关单。
- 餐品和库存无法回架时要有报损或转赠策略，不能当作没发生而忽略商家成本。
- 骑手侧结算按平台规则补偿，避免让骑手承担全部履约损失引发运力流失。
- 对用户提前展示取消扣费规则，减少「取消了为什么还扣钱」类客诉和重复咨询。
面试官可能追问
- 规则冲突时以合同还是体验为准？
- 如何防止利用取消刷券？
- 补偿消息失败怎么重试？
地理围栏误判用户不在配送范围，你怎么查？
考察点
- 坐标精度
- 围栏数据
- 降级
回答思路
这是数据质量与围栏精度问题；先保留现场证据再查算法，边界用户要有降级路径。
结构化参考答案
- 保留当时用户坐标、围栏版本号和计算服务日志，避免事后无法复盘误判原因。
- 检查坐标系转换、建筑物遮挡、围栏数据更新延迟等常见导致边界误判的因素。
- 边界模糊用户可走人工确认或二次定位，而不是硬拒绝直接流失可配送订单。
- 围栏数据发布要有灰度和回滚，避免一夜切错整城范围造成大面积误拒单。
面试官可能追问
- GPS 漂移你如何平滑？
- 室内定位失败怎么办？
- 围栏服务宕机默认开还是关？
运力不足时产品要延长预计送达，客服反对，你站哪边？
考察点
- 指标冲突
- 实验
- 沟通
回答思路
不站队某个人，站可验证的用户体验；用数据和实验化解产品与客服的指标冲突。
结构化参考答案
- 先看超时率、取消率和投诉分布，用数据说明延长 ETA 是减少爽约还是伤害下单转化。
- 建议分城市或小流量实验，而不是全国一刀切改预计送达，便于对比和回滚。
- 给客服准备统一话术和补偿预案，减少一线在规则变更期的解释压力和冲突。
- 约定固定回看窗口，到期用同一套指标复盘，决定继续放量还是恢复原策略。
面试官可能追问
- 实验期用户投诉上升你停不停？
- 如何避免只优化平台指标伤害骑手？
- 你如何记录这次决策？
和岗位、模拟面试一起用
资料管理里保存目标岗位 JD，模拟面试会按简历出题。点题目下的按钮会把本题带进模拟开场，仍需先绑定简历与岗位。