尧图网站建设 
Java 面试实录Spring Boot Kafka Redis Spring AI燕双非在互联网大厂的 3 轮过招场景互联网大厂 Java 求职面试。面试官严肃、问题刁钻候选人燕双非是个有点水但嘴很硬的程序员。简单题能答上来时面试官会顺势追问并夸赞复杂题一旦开始含糊现场就进入“看似懂了实际上没懂”的经典状态。第一轮订单系统与接口设计面试官我们先从电商下单接口开始。你用 Spring Boot 设计一个创建订单的 API会怎么组织 Controller、Service 和 DTO燕双非这题我熟。Controller 负责接收参数Service 负责业务DTO 专门做传输层次清晰避免实体乱飞。一般还会加上参数校验和统一返回体。面试官不错至少架构层次没乱。那如果这个接口要接入 OpenAPI/Swagger你会怎么做燕双非加注解呗给接口、参数、返回值都标清楚前后端联调会方便很多。面试官可以。那订单创建后需要落库并且要支持幂等你会怎么防重复提交燕双非嗯……可以先在 Redis 里放一个请求标识提交成功前校验一下有没有重复。或者前端按钮置灰双重保险。面试官思路对后面再细化一下幂等 token 的生成和过期策略。最后一个问题订单写库时你会优先考虑 MyBatis 还是 JPA为什么燕双非如果 SQL 复杂、性能要求高我可能偏 MyBatis如果领域模型比较清楚、CRUD 多就用 JPA省得写太多 SQL。面试官回答得还行至少知道取舍。继续。第二轮库存、消息与容错面试官现在订单创建成功后需要异步扣减库存并发送 Kafka 消息。为什么不用同步调用库存服务燕双非同步的话链路太长用户下单会慢而且库存服务一抖整个下单接口就跟着抖。异步用消息队列能削峰填谷还能提高系统解耦程度。面试官说得不错。那 Kafka 消息重复消费怎么处理燕双非嗯……消费者侧做幂等比如用业务唯一键落库前先查一下或者给消息加唯一 ID消费过就不再处理。面试官很好。那如果库存服务偶发超时怎么避免把链路拖垮燕双非可以用 Resilience4j 做超时、熔断、限流还能配合重试但重试次数不能太多不然容易雪上加霜。面试官这次回答比上次更像样了。那你在 Spring Cloud 体系里服务发现和配置中心会怎么选燕双非服务发现可以用 Nacos、Consul 或 Eureka配置中心也可以分开管理。现在大家更倾向于统一治理重点是动态更新和灰度能力。面试官不错至少知道云原生体系里的核心关注点。最后一个问题订单状态变化要发通知给用户你会用 RabbitMQ 还是 Kafka燕双非如果是业务通知、任务解耦我会考虑 RabbitMQ路由灵活如果是高吞吐事件流比如行为埋点、订单事件日志Kafka 更合适。面试官这个判断基本正确。继续第三轮。第三轮AI 能力与平台化升级面试官现在公司想在订单系统里加一个智能客服用 Spring AI 接入企业知识库。你觉得 RAG 的核心价值是什么燕双非RAG 就是先检索再生成。先从文档库里找相关内容再让大模型基于这些内容回答能减少胡说八道。面试官说得对。那怎么降低 AI 幻觉Hallucination燕双非要控制提示词优先让模型“只根据检索结果回答”还要做引用返回、答案置信度校验必要时拒答。面试官很好。那如果要把企业文档做向量化向量数据库你会怎么选燕双非看规模和生态。Milvus、Chroma、Redis 都能做关键是索引性能、召回效果、成本和运维复杂度。面试官不错。最后一个问题如果这个智能客服后面要支持工具调用比如查订单、查物流、退款申请你怎么理解 Agent 和工具执行框架燕双非Agent 相当于会规划步骤的“智能调度员”工具执行框架就是把查库、调接口这些能力标准化模型通过工具调用把任务拆开执行。这样能做复杂工作流。面试官嗯回答到了方向但细节还不够扎实。今天先到这里吧你回去等通知。所有问题详细解答1. Spring Boot 中如何设计创建订单 API在电商场景中创建订单接口通常包含 Controller、Service、Repository 三层。Controller 负责接收请求、参数校验、返回统一响应Service 负责订单创建、库存预占、优惠计算、幂等处理Repository 或 Mapper 负责持久化。推荐使用 DTO 作为请求和响应模型避免直接暴露数据库实体。这样可以隔离接口变更和领域模型变更提高可维护性。典型实践包括使用 Bean Validation 做参数校验使用统一异常处理返回业务错误码使用 OpenAPI/Swagger 做接口文档在 Service 层做事务控制保证订单和库存操作一致性。2. 如何用 Swagger/OpenAPI 提升联调效率在大厂项目里前后端并行开发很常见。Swagger/OpenAPI 能自动生成接口文档方便前端、测试、客户端理解接口约定。通过注解描述接口路径、参数、返回类型、错误码能减少沟通成本。建议同时维护接口示例、分页结构、枚举说明以及错误响应示例让文档更接近真实使用场景。3. 订单接口如何防止重复提交幂等是下单类接口的核心问题之一。常见做法包括前端提交按钮置灰仅做基础防护服务端生成幂等 Java 面试实录：Spring Boot + Kafka + Redis + Spring AI，燕双非在互联网大厂的 3 轮过招
Java 面试实录Spring Boot Kafka Redis Spring AI燕双非在互联网大厂的 3 轮过招场景互联网大厂 Java 求职面试。面试官严肃、问题刁钻候选人燕双非是个有点水但嘴很硬的程序员。简单题能答上来时面试官会顺势追问并夸赞复杂题一旦开始含糊现场就进入“看似懂了实际上没懂”的经典状态。第一轮订单系统与接口设计面试官我们先从电商下单接口开始。你用 Spring Boot 设计一个创建订单的 API会怎么组织 Controller、Service 和 DTO燕双非这题我熟。Controller 负责接收参数Service 负责业务DTO 专门做传输层次清晰避免实体乱飞。一般还会加上参数校验和统一返回体。面试官不错至少架构层次没乱。那如果这个接口要接入 OpenAPI/Swagger你会怎么做燕双非加注解呗给接口、参数、返回值都标清楚前后端联调会方便很多。面试官可以。那订单创建后需要落库并且要支持幂等你会怎么防重复提交燕双非嗯……可以先在 Redis 里放一个请求标识提交成功前校验一下有没有重复。或者前端按钮置灰双重保险。面试官思路对后面再细化一下幂等 token 的生成和过期策略。最后一个问题订单写库时你会优先考虑 MyBatis 还是 JPA为什么燕双非如果 SQL 复杂、性能要求高我可能偏 MyBatis如果领域模型比较清楚、CRUD 多就用 JPA省得写太多 SQL。面试官回答得还行至少知道取舍。继续。第二轮库存、消息与容错面试官现在订单创建成功后需要异步扣减库存并发送 Kafka 消息。为什么不用同步调用库存服务燕双非同步的话链路太长用户下单会慢而且库存服务一抖整个下单接口就跟着抖。异步用消息队列能削峰填谷还能提高系统解耦程度。面试官说得不错。那 Kafka 消息重复消费怎么处理燕双非嗯……消费者侧做幂等比如用业务唯一键落库前先查一下或者给消息加唯一 ID消费过就不再处理。面试官很好。那如果库存服务偶发超时怎么避免把链路拖垮燕双非可以用 Resilience4j 做超时、熔断、限流还能配合重试但重试次数不能太多不然容易雪上加霜。面试官这次回答比上次更像样了。那你在 Spring Cloud 体系里服务发现和配置中心会怎么选燕双非服务发现可以用 Nacos、Consul 或 Eureka配置中心也可以分开管理。现在大家更倾向于统一治理重点是动态更新和灰度能力。面试官不错至少知道云原生体系里的核心关注点。最后一个问题订单状态变化要发通知给用户你会用 RabbitMQ 还是 Kafka燕双非如果是业务通知、任务解耦我会考虑 RabbitMQ路由灵活如果是高吞吐事件流比如行为埋点、订单事件日志Kafka 更合适。面试官这个判断基本正确。继续第三轮。第三轮AI 能力与平台化升级面试官现在公司想在订单系统里加一个智能客服用 Spring AI 接入企业知识库。你觉得 RAG 的核心价值是什么燕双非RAG 就是先检索再生成。先从文档库里找相关内容再让大模型基于这些内容回答能减少胡说八道。面试官说得对。那怎么降低 AI 幻觉Hallucination燕双非要控制提示词优先让模型“只根据检索结果回答”还要做引用返回、答案置信度校验必要时拒答。面试官很好。那如果要把企业文档做向量化向量数据库你会怎么选燕双非看规模和生态。Milvus、Chroma、Redis 都能做关键是索引性能、召回效果、成本和运维复杂度。面试官不错。最后一个问题如果这个智能客服后面要支持工具调用比如查订单、查物流、退款申请你怎么理解 Agent 和工具执行框架燕双非Agent 相当于会规划步骤的“智能调度员”工具执行框架就是把查库、调接口这些能力标准化模型通过工具调用把任务拆开执行。这样能做复杂工作流。面试官嗯回答到了方向但细节还不够扎实。今天先到这里吧你回去等通知。所有问题详细解答1. Spring Boot 中如何设计创建订单 API在电商场景中创建订单接口通常包含 Controller、Service、Repository 三层。Controller 负责接收请求、参数校验、返回统一响应Service 负责订单创建、库存预占、优惠计算、幂等处理Repository 或 Mapper 负责持久化。推荐使用 DTO 作为请求和响应模型避免直接暴露数据库实体。这样可以隔离接口变更和领域模型变更提高可维护性。典型实践包括使用 Bean Validation 做参数校验使用统一异常处理返回业务错误码使用 OpenAPI/Swagger 做接口文档在 Service 层做事务控制保证订单和库存操作一致性。2. 如何用 Swagger/OpenAPI 提升联调效率在大厂项目里前后端并行开发很常见。Swagger/OpenAPI 能自动生成接口文档方便前端、测试、客户端理解接口约定。通过注解描述接口路径、参数、返回类型、错误码能减少沟通成本。建议同时维护接口示例、分页结构、枚举说明以及错误响应示例让文档更接近真实使用场景。3. 订单接口如何防止重复提交幂等是下单类接口的核心问题之一。常见做法包括前端提交按钮置灰仅做基础防护服务端生成幂等