Java 面试实战Spring Boot Kafka Redis Spring Security AI 在电商与智能客服场景下的三轮深度拷问场景某互联网大厂电商与智能客服平台 Java 岗位面试。人物面试官严肃、燕双非搞笑的水货程序员简单题能答复杂题开始含糊其辞。第一轮基础与核心链路面试官先说说你们订单服务为什么选 Spring Boot而不是传统 Spring MVC 手工装配燕双非Spring Boot 开箱即用嘛自动配置、starter 依赖、内嵌容器项目启动快少写很多 XML。对订单这种高频迭代服务确实能提升开发效率。面试官不错能把“快”和“少配置”说清楚。那你们是怎么用 MyBatis 处理订单写入的燕双非我们一般就是 Mapper 接口加 XML复杂 SQL 更容易控制。下单时先插订单主表再插订单明细事务要包住不然数据会不一致。面试官可以说明你知道事务边界。那库存扣减后为什么要发 Kafka 事件而不是直接同步调用库存系统燕双非呃……因为同步太慢了吧。Kafka 异步解耦订单服务先返回库存服务自己慢慢处理压力也能分摊。面试官方向对。那如果消息重复消费了你怎么保证幂等燕双非这个……可以用订单号做唯一键消费前先查一下数据库或者 Redis 里有没有处理过有的话就直接跳过。面试官回答还行至少知道幂等不是靠“运气”。第二轮链路治理与安全面试官电商活动大促时商品详情页和购物车访问量很大你们 Redis 怎么设计缓存燕双非商品详情可以做缓存热点数据放 Redis。要设置合理 TTL防止脏数据太久。还有缓存穿透可以加空值缓存或者布隆过滤器。面试官可以已经有缓存意识了。那缓存雪崩和击穿呢燕双非雪崩就是很多 key 一起过期得给 TTL 加随机值击穿就是热点 key 失效瞬间有大量请求打到数据库得加互斥锁或者逻辑过期。面试官不错思路比较完整。继续说用户登录和支付鉴权你们怎么做燕双非我们用 Spring Security JWT。登录成功后签发 token前端带着 token 调接口后端解析 token 并校验权限。面试官那 JWT 无状态带来了什么问题燕双非嗯……不好做强制下线token 过期前都有效。所以一般会配合黑名单、短有效期、刷新 token 这些机制。面试官可以说明你没把无状态理解成“无脑”。再说一下你们怎么监控下单链路的性能燕双非我们会接 Micrometer对接 Prometheus 和 Grafana关注接口耗时、QPS、错误率。还有日志统一用 SLF4J 输出排查问题方便。面试官挺好知道指标不是“看个大概”。第三轮AI 与复杂业务演进面试官现在很多电商都在做智能客服。假设你负责接入 Spring AI怎么让客服回答商品、物流、退换货问题燕双非先把商品、规则、知识库文档做加载和切分然后向量化存到向量数据库里。用户提问后做语义检索再把检索结果和问题一起拼到提示词里交给大模型。面试官不错已经提到 RAG 了。那为什么不能只靠大模型直接回答燕双非因为它可能会幻觉乱编答案。业务上尤其是退换货和价格规则必须结合企业知识库和实时数据不然客服会胡说八道。面试官那如果要做一个“订单问题自动处理 Agent”你会怎么设计工具调用燕双非嗯……就是给它几个工具比如查订单、查物流、查退款状态让 Agent 根据用户意图自己选工具。最好把工具接口标准化不然每接一个系统都很乱。面试官思路对已经接近生产设计了。最后一个问题假如客服系统要支持高并发会话你怎么保存聊天会话内存燕双非可以把会话状态存 Redis按用户和会话 ID 做隔离。这样多实例部署时也能共享上下文避免模型每次都“失忆”。面试官行今天先到这里。你回去等通知吧。详细解答逐题拆解与业务落地1. 为什么订单服务选 Spring Boot在电商订单系统中Spring Boot 的优势不是“更高级”而是更适合快速交付和标准化治理。自动配置能减少样板代码starter 让依赖收敛内嵌容器使部署方式更统一。对订单、购物车、客服这类变化快的业务团队通常更希望把精力放在业务逻辑和稳定性上而不是繁琐装配。2. MyBatis 处理订单写入的价值订单写入通常涉及主表、明细表、优惠信息、支付流水等多表操作。MyBatis 的优势在于 SQL 可控适合复杂查询和精细化优化。业务上建议将“创建订单”作为事务边界确保主表和明细一致同时配合唯一订单号、乐观锁或状态机避免重复创建。3. 为什么下单后发 Kafka 事件在高并发场景中同步调用库存、营销、积分系统会放大链路耗时也会增加级联失败风险。Kafka 适合做事件驱动订单创建成功后发送“订单已创建”消息库存、营销、风控各自消费。这样可以实现解耦、削峰和异步处理提高系统可用性。4. 消息幂等怎么做幂等的核心是同一业务事件被重复执行结果仍然正确。常见做法包括业务唯一键去重、消费日志表、Redis 去重标记、数据库唯一约束、状态机校验等