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

简历给你了学校标的清清楚楚😅，面完说我是三本只能给150，那你boss标200-250干嘛，感觉还是太礼貌了，应该直接爆了😤学历就是一个人的外貌实习就是一个人的衣服本科学历差就是其貌不扬的样子实习经历差就是破破烂烂的衣服＃民办已经死了 ＃都给我去考研吧＃计算机就是学历＞技术＃c++92✌🏻才能学

要简历的不少，但没面😥同学都在实习，好焦虑😢

腾讯一面（腾讯云）2026/4/71、React Native 跨端改造遇到的问题（核心问）你负责 RN 改造哪些模块？任务列表、订阅购买、任务展示、用户中心等通用业务。跨端模块怎么划分？ 三层架构：公共层：业务逻辑、Hooks、工具、请求（70% 复用）适配层：端差异集中聚合（支付、通知、安全区、原生能力）业务层：只调用统一接口，不写零散 Platform 判断为什么不直接在业务里写 Platform？避免到处判断、难维护、易出 bug；所有差异集中收口，统一维护。是别人给方案还是你自己设计？leader 给方向，我自己做模块拆分、差异收敛、目录规划，按 “高复用 + 低耦合” 落地。2、国...