1. 自我介绍2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”...

目标后端

流程挺快的, 一面和二面的间隔大一点, 二面完几分钟就三面了1. 自我介绍2. 实习拷打 大部分时间都在实习上 总时长感觉1小时左右, 一半的时间都在问实习3. 特征筛选如果不只看相关系数，你会怎么做特征筛选不能只看单变量相关性，因为很多特征单独看不强，但和其他特征组合后才有信息量。更稳的做法通常是先做业务分组和统计稳定性检查，过滤掉高缺失、高漂移、强泄漏和强共线的特征；再结合树模型增益、置换重要性、SHAP 分析和线上可用性做二次筛选。对大模型应用相关任务，还要额外关注特征是不是把未来信息泄漏进来了，比如用到了答案后的行为、后验标签或者系统回写字段。真正好的特征不是“看起来复杂”，而是对目标...