一、面试场景互联网大厂 Java 岗位今天面试的是一位来自电商 AIGC方向的 Java 求职者名字很响亮江湖人称燕双非。他平时写代码风格比较“随缘”但自信心很足。面试官则是典型的大厂风格严肃、冷静、问题层层递进喜欢从业务场景出发把候选人往深处问。二、第一轮基础能力与系统认知面试官先聊一个简单的。你做过电商订单系统吗如果下单接口要支持高并发你会先从哪几方面入手燕双非这个我熟。先加 Redis 缓存再加线程池最后把数据库调大一点应该就稳了。面试官方向不算错但还不够完整。那你说说 Spring Boot 在这种系统里主要解决了什么问题燕双非Spring Boot 就是帮我们少写配置开箱即用。比如自动装配、嵌入式容器、统一依赖管理能让项目启动更快开发更省事。面试官回答得可以。那如果订单服务需要接入支付、库存、优惠券三个模块你会怎么设计接口的调用链燕双非我会先做一个订单主流程然后用 Feign 或者 RPC 去调别的服务失败了就重试不行就降级。面试官思路有了。那你知道重试和幂等的区别吗燕双非重试就是失败了再试一次幂等就是……多次调用结果应该差不多吧。面试官“差不多”这词在生产里不太安全后面我们细聊。三、第二轮中间件、缓存与消息链路面试官假设订单创建后要异步发短信、发优惠券、写审计日志你会选什么方案燕双非我会用 Kafka。订单落库后发消息短信和券系统各自消费解耦一下。面试官不错。那如果 Kafka 消息重复消费了你怎么处理燕双非可以在消费端做去重比如用订单号做唯一键或者查一下 Redis 标记这条消息是否处理过。面试官这个回答有实战味道。那 Redis 在电商里除了缓存商品详情还能做什么燕双非还能做库存预扣、分布式锁、验证码、购物车、排行榜……反正能塞进去的都可以塞进去。面试官能说到这些说明不是完全没做过。那分布式锁你会怎么实现为什么不能只用一个setnx燕双非嗯……加个过期时间防止死锁。至于为什么不能只用一个 setnx……因为可能会有并发问题面试官还行但你要能讲清楚锁续期、误删、原子性这些点。面试官再问一个消息链路问题订单支付成功后库存系统、积分系统、营销系统都要联动你怎么保证整体可靠性燕双非我会考虑事务消息、最终一致性、补偿机制还有死信队列。大概就是别把所有事情都赌在一次调用上。面试官这句话很到位。你比刚才清醒了一点。四、第三轮安全、AI 与架构升级面试官现在电商平台开始接入 AI 导购。用户说“帮我推荐适合 25 岁程序员的通勤鞋”系统要怎么做燕双非我觉得可以先做一个 RAG把商品知识库检索出来再交给大模型生成推荐结果。面试官继续。RAG 里为什么还要做向量化和语义检索燕双非因为用户问法不一定和商品标题一致。比如“通勤鞋”和“上班鞋”其实意思接近向量检索能找到语义相近的内容。面试官很好。那如果你要把企业商品文档、规则文档、促销策略文档一起接入 AI 问答系统怎么控制幻觉燕双非要限制模型只基于检索结果回答提示词里加约束必要时引用来源另外要做权限控制避免乱答敏感信息。面试官那你对 Agent 了解多少燕双非Agent 就是让模型自己决定下一步要不要调用工具比如查库存、查订单、发券、创建工单。它比单纯问答更像一个能干活的助手。面试官对方向是对的。那如果这个 AI 导购系统要对接多个内部工具你怎么设计工具调用标准化燕双非需要统一工具描述、输入输出格式和鉴权方式最好做成客户端-服务器架构这样不同团队接入起来更方便。面试官最后一个问题用户登录、下单、AI 导购、消息通知都涉及权限控制你会怎么结合 Spring Security 和 JWT 设计燕双非登录后签发 JWT前端每次请求带上 token服务端做校验和权限鉴定。Spring Security 负责认证授权细粒度权限可以按角色、接口、资源维度控制。面试官嗯今天聊到这里。整体上你有一些项目经验但细节还需要再打磨。你先回家等通知吧。五、问题详解把面试题讲透1. 高并发订单接口如何设计电商下单接口的核心不是“快”而是“快且稳”。典型做法包括热点数据用 Redis 缓存减少数据库压力库存扣减要考虑原子性避免超卖接口要支持幂等防止重复提交异步化处理非核心流程如短信、积分、审计必要时做限流、熔断、降级。业务上用户下单时并不需要所有子流程同步完成。可以先完成订单主记录再通过消息驱动后续动作。2. Spring Boot 在系统中的价值Spring Boot 的核心价值是降低开发和部署成本。它通过自动装配、Starter 依赖、内嵌容器、统一配置管理让业务团队可以更快搭建服务。在大厂中Spring Boot 常作为微服务基础框架承担统一启动、监控接入、配置中心集成等职责。3. 幂等、重试与分布式调用链重试是失败后再次调用幂等是重复调用多次结果仍然一致。二者不是一回事。典型幂等方案包括使用业务唯一号如订单号、请求号数据库唯一索引约束Redis 记录请求指纹状态机控制避免非法重复推进。在分布式系统中重试会放大流量因此必须结合幂等否则很容易造成重复扣库存、重复发券。4. Kafka 异步解耦与消息可靠性Kafka 很适合订单事件驱动架构。订单支付成功后向 Kafka 发送“支付成功事件”库存、积分、营销等服务分别订阅消费。但消息系统不是银弹需要关注消息重复消费者必须幂等消息丢失需要生产端确认、合理的副本配置消息积压要监控消费速度与堆积量顺序性局部顺序要靠分区键设计。对于“下单-支付-发货”链路最常见方案是最终一致性配合补偿任务和死信队列。5. Redis 的典型业务用途Redis 不只是缓存也常承担以下职责购物车高频读写、结构简单验证码短期存储、过期自动清理排行榜ZSet 实现实时排序分布式锁控制共享资源并发库存预扣降低数据库并发冲突消息去重辅助消费幂等。分布式锁要注意锁过期、误删、锁续期等问题通常需要原子操作和唯一标识来保证安全释放。6. Redis 分布式锁为什么不能只写 setnx单纯setnx只负责“抢到锁”但不代表锁是安全的。问题包括拿到锁后服务宕机锁可能永远不释放业务执行时间超长锁提前过期别的线程又拿到锁误删别人的锁造成并发安全问题。更稳妥的方式是加唯一 token 过期时间 Lua 脚本原子释放 必要的续期机制。7. AI 导购中的 RAG 思路RAG 的核心是先检索再生成。适用于商品推荐、客服问答、企业知识库查询等场景。典型流程文档加载商品说明、规则、活动页面、FAQ切分与向量化把文本转为 embedding存入向量数据库如 Milvus、Chroma、Redis Vector用户提问后做语义检索将检索结果拼接进提示词大模型基于上下文生成回答。这种方式能减少幻觉因为模型回答时有“可依赖的材料”。8. 如何控制 AI 幻觉幻觉是大模型“看起来很懂、实际上乱编”的问题。控制方式包括让模型只依据检索内容回答为回答加引用来源对敏感问题设置拒答策略做答案校验和事实核验对高风险业务引入人工审核。在企业场景里AI 不能只追求“能说”更要追求“说得对”。9. Agent 的价值Agent 不只是聊天它强调规划、决策、执行。例如智能客服可以自动完成识别用户意图查询订单状态判断是否需要转人工自动创建售后工单根据规则触发补偿。Agent 的优势在于能调用工具完成闭环任务适合复杂工作流。10. Spring Security JWT 的常见组合JWT 负责无状态身份传递Spring Security 负责认证与授权。登录成功后签发 token后续请求携带 token服务端解析后构建用户上下文并根据角色或权限判断是否放行。在多服务系统里这种方式比较适合前后端分离和微服务架构但要注意 token 失效、刷新、黑名单以及敏感操作二次校验。六、总结这场面试看起来像是电商系统、消息中间件、缓存治理、AI 导购、安全体系的综合题实际上考察的是候选人对业务链路、系统设计、工程化思维和AI 落地能力的整体理解。如果你正在准备互联网大厂 Java 面试建议把“技术点”放回到“业务场景”里去理解这样更容易真正讲清楚也更容易在面试中脱颖而出。感谢阅读希望这篇文章能帮助到你祝你面试顺利早日拿到满意的 offer