互联网大厂 Java 面试实战：Spring Boot + MyBatis + Redis + Kafka + JWT + Spring Cloud + WebFlux + Spring AI
场景：某互联网大厂电商业务线终面。面试官风格严肃、追问犀利；候选人小Y人设是"嘴上很会、细节容易飘"的水货程序员。前两轮问题聚焦基础与常见业务，第三轮逐步引入微服务、云原生和 AI 能力，最后给出适合小白背诵和理解的参考答案。
第一轮：电商下单链路，先看基本功
问题 1：
面试官：如果让你做一个电商下单接口，你会怎么设计？先说整体技术选型。
小Y ：这个简单，我一般会用 Spring Boot 起服务，接 MyBatis 或 Spring Data JDBC 写订单表，再配个 Redis 做缓存，数据库连接池用 HikariCP，日志用 SLF4J + Logback。如果要控制事务，我会优先保证库存扣减、订单创建、支付状态这几个核心步骤。
面试官：嗯，至少没把事务和缓存顺序说反，继续。
问题 2：
面试官：下单时为什么不能先写缓存再写数据库？
小Y：因为缓存不是最终一致的真相来源，如果先写缓存再落库，中间服务挂了，缓存里有订单，数据库却没有，后面查询和补偿都会乱。
面试官：这个方向对，继续展开一下。
问题 3：
面试官：那库存和订单怎么保证一致性？你会选什么方案？
小Y ：如果是高并发秒杀，我会用 Redis 先做预扣减，后面通过 Kafka 异步落库；如果是普通下单，可以用数据库事务加乐观锁，或者配合 Spring Transaction，把订单创建和库存扣减放在同一个本地事务里。要是跨服务，我可能会用 Seata，不过你们题目里没列，我就不展开了。
面试官：至少知道分场景，不是上来就"分布式事务一把梭"。
问题 4：
面试官：如果订单创建成功，但消息没发出去怎么办？
小Y ：这就要用"本地消息表"或者"事务消息"思路。先把订单状态和待发送消息一起落库，再由定时任务或后台线程补发。Kafka 的消息至少一次投递很常见，所以消费者端也要做幂等，比如用订单号去重。
面试官：这回答比很多只会背八股的人强一点。
第二轮：扩展到会员、支付和权限，开始追问细节
问题 1：
面试官：如果这个电商系统要支持登录、下单、支付回调，你会怎么做认证和鉴权？
小Y ：登录我会优先用 Spring Security，如果是前后端分离，就发 JWT 给前端。用户请求带 token 进来后，网关或者后端过滤器校验签名、过期时间和用户权限。支付回调这类接口，我会单独放开白名单，但要校验签名，不能只靠"是支付平台打来的"这种天真判断。
面试官：嗯，知道回调不能裸奔，继续。
问题 2：
面试官：JWT 自己带状态，为什么很多公司还会配 Redis？
小Y ：JWT 是无状态的，优点是服务端压力小，但缺点是吊销不方便。所以常见做法是把 token 的黑名单、刷新 token、登录态版本号放在 Redis 里。这样一旦用户改密码、被踢下线、设备丢失，就能快速失效。
面试官：不错，答到"怎么失效"比只会说"无状态"更重要。
问题 3：
面试官：支付回调里最怕什么问题？
小Y：最怕重复通知、乱序通知、伪造通知。重复通知要靠幂等，乱序通知要看状态机，伪造通知要校验签名、证书、时间戳。业务上最好把订单状态设计成有限状态机，比如：待支付、已支付、已发货、已完成、已关闭，状态只能单向流转。
面试官：这题答得像个做过支付的。
问题 4：
面试官：如果支付成功后，库存扣减失败了怎么办？
小Y ：那就进入补偿流程。可以先把支付成功事件写到 Kafka，库存服务消费失败后重试；如果重试仍失败，就生成补偿单，人工介入或自动退款。实际系统里还会配合 Resilience4j 做熔断、限流、重试，避免某个下游故障拖垮主链路。
面试官：开始像样了。别急，后面还有更难的。
第三轮：微服务、云原生、AI 化客服与检索
问题 1：
面试官：现在老板要求把订单、库存、会员、客服拆成微服务，你怎么做服务治理？
小Y ：服务发现可以用 Eureka 或 Consul，服务调用可以用 OpenFeign，接口聚合可以考虑网关。内部高性能调用可以用 gRPC，如果是跨语言或者老系统也可能接 Thrift。熔断、限流、重试交给 Resilience4j。如果是 Spring Cloud 体系，基本链路就能搭起来。
面试官：嗯，知道"发现、调用、保护"三件套。
问题 2：
面试官：如果客服系统要做"智能问答"，怎么避免大模型胡说八道？
小Y ：这个就得做 RAG，也就是检索增强生成。先把商品知识、退款规则、物流政策、FAQ 文档做文档加载和切分，再向量化，放到 Milvus、Chroma 或 Redis 这类向量存储里。用户提问时先做语义检索，拿到相关上下文，再喂给大模型生成答案。这样比纯聊天更稳，能明显降低 AI 幻觉。
面试官：这题是加分题，你答到点子上了。
问题 3：
面试官：如果客服要支持"查订单、改地址、查物流"这种动作，光问答不够，怎么做？
小Y ：要做 Agent，也就是智能代理。大模型负责理解意图，然后通过工具调用框架去执行具体动作，比如查订单接口、物流查询接口、改地址接口。这里要强调工具调用标准化，否则每个工具都接一套，后面维护会疯掉。还要控制权限、审计日志和超时，不能让模型乱调接口。
面试官：对，不能只会"回答问题"，还要会"办事"。
问题 4：
面试官：那你会怎么把这个系统部署到云原生环境里？
小Y ：应用用 Docker 打包，部署到 Kubernetes。配置从环境变量和配置中心注入，健康检查要做 liveness/readiness。监控方面可以用 Micrometer 暴露指标，再接 Prometheus + Grafana，链路追踪可以上 Jaeger 或 Zipkin，日志统一进 ELK Stack。如果是压测或线上排障，也能更快定位接口慢、消息堆积、缓存穿透这些问题。
面试官：行，至少不是"容器化就是把 jar 扔进镜像"这种回答了。
问题 5：
面试官：最后一个问题，假设你们业务要同时做电商客服、知识库问答、工单流转，还要接入企业内部文档，整体方案怎么串起来？
小Y ：我会把它拆成三层：第一层是文档与数据接入，支持 Word/PDF/网页 等内容加载；第二层是检索与向量化，用 Embedding 模型把内容变成向量，放入向量数据库；第三层是对话和执行层，基于 Spring AI 或类似框架做 prompt 组装、工具调用、会话记忆、复杂工作流编排。对于企业文档问答，回答必须带来源片段，必要时做引用溯源。对于工单流转，Agent 要能调用创建工单、查询状态、升级人工等工具。
面试官：思路是对的，但我还想听你讲讲边界和风险。
小Y：边界就是别让模型直接决定高风险操作，比如退款、改价、销户；这类要加人工确认。风险主要是幻觉、权限越界、检索不到答案、上下文过长。控制手段包括提示词约束、检索阈值、结果重排、权限校验、审计记录和灰度上线。
面试官：行了，今天先到这。你回去等通知吧。
参考答案详解：面试官到底想听什么
1. 电商下单链路的核心设计
一个常见的电商下单流程通常包括：
- 用户提交订单请求
- 服务端校验登录态、库存、优惠券、风控规则
- 创建订单记录
- 扣减库存
- 发送支付或订单事件
- 返回下单结果
这里最关键的是"一致性 "和"幂等性"。
- 一致性：订单创建和库存扣减必须保证业务上不能乱。
- 幂等性：无论是前端重复点击，还是消息重复投递，都不能造成重复下单或重复扣库存。
常见技术组合：
Spring Boot：快速搭建服务MyBatis/JPA：持久化订单和库存HikariCP：数据库连接池Redis：库存预扣减、分布式锁、登录态、限流Kafka：异步事件通知、削峰填谷Flyway/Liquibase：数据库版本管理
2. JWT、Spring Security 和 Redis 的关系
JWT 适合无状态认证，适合前后端分离和微服务场景，但它有两个现实问题：
- token 一旦签发，在过期前很难强制失效
- token 内容如果设计不当，可能暴露敏感信息
所以常见做法是：
Spring Security负责认证和授权JWT负责传递身份信息Redis保存黑名单、刷新令牌、登录版本号
这样既保留了无状态的性能优势，又能实现踢下线、改密失效等能力。
3. 支付回调为什么一定要幂等
支付平台往往会重复通知，原因可能是网络超时、重试机制、对方系统确认失败等。你的系统如果每次都直接把订单改成"已支付"，就可能出现重复发货、重复记账。
所以要做到：
- 回调验签，防伪造
- 状态机限制流转，防乱序
- 幂等校验，防重复
- 失败补偿，防消息丢失
常见设计是先更新支付流水表，再驱动订单状态变更，必要时通过 Kafka 做异步解耦。
4. 微服务治理的四个关键词
拆成微服务之后，不能只看"能拆开"，还要看"能稳定运行"。面试官通常希望你提到：
- 服务发现：
Eureka、Consul - 服务调用：
OpenFeign、gRPC - 容错治理：
Resilience4j - 可观测性：
Micrometer、Prometheus、Grafana、Jaeger、Zipkin、ELK Stack
这些东西拼起来，才是一个能上线的微服务体系。
5. RAG 为什么比纯大模型更适合企业问答
企业场景最怕模型"瞎编"。RAG 的核心思想就是：
- 不直接让模型凭记忆回答
- 先从企业知识库里检索相关资料
- 再把检索结果作为上下文交给模型生成答案
完整流程通常是：
- 文档加载：导入 FAQ、制度、商品说明、工单知识
- 切分文本：按段落或语义切块
- 向量化：用
Embedding模型生成向量 - 存储检索：放入
Milvus、Chroma、Redis等向量库 - 语义检索：根据用户问题召回最相关片段
- 生成答案：把检索结果连同问题输入大模型
- 结果约束：输出来源、置信度、免责声明
这样可以明显降低幻觉，并且更适合企业知识问答、智能客服和工单助手。
6. Agent 为什么比普通问答更进一步
普通问答只能"说"，不能"做"。Agent 的价值在于把自然语言变成动作：
- 查询订单
- 创建工单
- 查询物流
- 修改地址
- 调用审批流程
它的关键不只是"让模型会调接口"，而是要做到：
- 工具标准化
- 权限校验
- 审计追踪
- 超时重试
- 失败回退
如果企业里有复杂工作流，比如客服转人工、售后退款审批、供应链异常处理，Agentic RAG 和工具调用框架就会非常有用。
7. 云原生部署时要关注什么
真正的上线环境里，代码之外的问题往往更多：
Docker负责镜像封装Kubernetes负责弹性伸缩和调度Micrometer负责指标采集Prometheus + Grafana负责监控展示Jaeger / Zipkin负责链路追踪ELK Stack负责日志检索
如果不做这些，出了问题只能"靠猜"。
8. 小Y这类回答在面试里为什么有时能过
因为面试官不只看你会不会背名词，还看你能不能把：
- 业务问题
- 技术方案
- 风险控制
- 落地细节
串成一条完整链路。小Y虽然有点"油"，但在简单问题上答得稳、在复杂问题上能说出主线，就已经比很多只会背概念的人强了。
一句话总结
互联网大厂 Java 面试最看重的，不是你会多少技术名词，而是你能不能把"业务场景 -> 架构设计 -> 技术实现 -> 风险治理 -> 可观测性 -> AI 增强"完整讲清楚。