从 Spring Boot 微服务到 RAG 智能客服：一场互联网大厂 Java 面试全解析

场景：本地生活服务平台 + AI 智能客服 + 支付与风控

角色：

  • 严肃面试官：Z 经理（互联网大厂 Java 技术负责人）
  • 搞笑水货程序员：小 Y（简历写满了：Spring 全家桶、微服务、AI、RAG、Agent……）

开场：业务场景设定

Z 经理：

我们公司做本地生活服务平台：团购、外卖、到店核销，类似「某团」。 现在要做一套 智能客服系统 + 订单服务 + 支付风控，你面试的岗位是 Java 后端开发 + AI 应用落地。 我会按场景循序渐进问问题。

小 Y：

没问题，我对 Spring Boot、Spring Cloud、Kubernetes、RAG、Agentic Workflow 都非常熟……（声音越来越小）

Z 经理：

行，那我们开始。

第一轮：基础服务与接口设计（偏简单）

主题：本地生活服务的「商家与订单」基础服务，用 Spring Boot/Maven/REST/Swagger/MyBatis/Redis。

问题 1：如何用 Spring Boot 设计商家查询接口？

Z 经理：

现在有「商家服务」，需要提供一个根据商家 ID 查询详情的 HTTP API。

要求：

  1. 用 Spring Boot 开发，
  2. 使用 REST 风格，
  3. 要有接口文档（Swagger/OpenAPI）。

你会怎么设计？

小 Y：

这个简单，我一般这么写：

  • 用 Spring Initializr 建个 Spring Boot 项目，选 Spring Web。
  • @RestController 开一个 MerchantController，方法用 @GetMapping("/api/merchants/{id}")。
  • 返回一个 MerchantDTO，用 @PathVariable Long id 接收参数。
  • 接口文档就加个 Swagger 注解，比如 @Operation(summary = "查询商家详情")。

然后我就……emm，差不多就这样吧。

Z 经理：

回答得还可以，至少接口风格和 Swagger 思路是对的。

问题 2：数据库和 MyBatis 怎么接？

Z 经理：

商家数据在 MySQL 里，表叫 merchant，字段有 id、name、address、status 等。 你怎么用 MyBatis 或 MyBatis-Plus 访问数据库，保证基本的可维护性？

小 Y：

我可以用 MyBatis-Plus，写个 MerchantMapper 接口继承 BaseMapper<Merchant>， 然后用 @Mapper 标注就好了，想查就 selectById(id)，很丝滑。

至于 SQL 优化，我觉得先用着，慢了再说……

Z 经理：

至少知道 MyBatis-Plus 的用法，不过生产里我们会对 SQL、索引和事务有更多要求，后面详细聊。

问题 3：Redis 缓存商家信息怎么设计？

Z 经理：

商家信息变化不频繁，但读请求非常多，我们希望做缓存。 用 Redis 来缓存商家信息，你会怎么设计 Key、如何设置过期时间、如何防止缓存击穿？

小 Y：

Key 我一般用 merchant:{id}，比如 merchant:1001。

过期时间嘛……设个 30 分钟或者 1 小时，看心情。

至于缓存击穿，我会先查缓存：

  • 有就直接返回；
  • 没有就查数据库，查到了顺便塞回 Redis；

这样就不会击穿了吧？

Z 经理：

思路是对一半，但击穿、雪崩、穿透不止这些处理方式，后面解析部分我会详细讲。

问题 4：如何对查询接口做单元测试？

Z 经理：

用 JUnit 5 和 Mockito 给 MerchantService 写一个单元测试，你大致会怎么写？

小 Y：

这个我挺熟：

  • @ExtendWith(MockitoExtension.class) 开个测试类。
  • 用 @Mock 一个 MerchantMapper，然后 @InjectMocks 一个 MerchantServiceImpl。
  • 模拟 when(merchantMapper.selectById(1L)).thenReturn(merchant)。
  • 然后调用 merchantService.getById(1L)，再用 Assertions.assertEquals 验证。

大概就这套路。

Z 经理：

还不错，单测思路是正确的。

问题 5：如何用 Swagger/OpenAPI 统一管理接口文档？

Z 经理：

公司前后端分离，我们要统一维护 API 文档。 你打算用 Swagger／OpenAPI 做哪些事情？

小 Y：

我会在项目里引入 springdoc-openapi，然后：

  • 控制器方法上加 @Operation、@Parameter 等注解；
  • 启动后访问 /swagger-ui.html 或 /swagger-ui/index.html；
  • 前端可以直接看接口文档，甚至导出 OpenAPI JSON 给别的团队用。

还可以用它生成一些客户端代码吧……我没具体用过。

Z 经理：

基础了解还行，细节我们等下在解析里补充。

第二轮：微服务拆分、消息与支付风控（难度提升）

主题：订单服务 + 支付服务 + 风控服务，用 Spring Cloud、Kafka、Redis、JWT、ELK 等。

问题 1：订单、支付、风控微服务如何拆分？

Z 经理：

在本地生活平台里，下单到支付到风控，大概有哪些服务？你会如何拆分微服务，服务之间怎么调用？

小 Y：

我觉得可以分：

  • order-service：负责创建订单；
  • payment-service：负责支付；
  • risk-service：负责风控；
  • 还有用户、商家服务之类的。

调用的话，直接 RestTemplate / WebClient 调用就好，或者用 OpenFeign。大概就这样。

Z 经理：

拆分方向还可以，但缺少边界和数据一致性这些关键点，后面我会在解析部分展开。

问题 2：用 Kafka 解耦订单与风控

Z 经理：

用户下单后，我们希望把订单数据发送到风控系统做异步核查。我们使用 Kafka。

请你描述一下：

  • order-service 怎么发消息？
  • risk-service 怎么消费？
  • 如何保证消息不会轻易丢失？

小 Y：

我会在 order-service 里注入一个 KafkaTemplate，然后下单成功后：

kafkaTemplate.send("order-created", orderJson);

然后 risk-service 开一个 @KafkaListener(topics = "order-created") 去消费。

保证不丢消息……Kafka 本身就很可靠吧，我记得还有 acks=all 之类的参数可以开一下。

Z 经理：

有点印象，但生产里还有很多幂等等问题待考虑。

问题 3：支付接口如何做安全和鉴权（Spring Security + JWT）？

Z 经理：

支付接口是核心高风险接口，我们既要鉴权，也要避免被伪造请求刷接口。

公司技术栈：Spring Security + JWT + Nginx 反向代理。

你会从哪些层面做安全设计？

小 Y：

我先用 Spring Security 把支付接口保护起来，只允许登录用户访问； 然后用 JWT 做登录凭证，用户登录后发一个 Token，后面每次请求带上；

然后 Nginx 限流一下就安全了……

Z 经理：

这算一种思路，但没有提签名、防重放、幂等等，后面我会详细补充。

问题 4：如何监控支付成功率与错误？（ELK + Prometheus + Grafana）

Z 经理：

线上最怕支付异常，老板半夜会打电话。

你会怎么用日志和监控体系，比如 ELK Stack、Prometheus、Grafana，来监控支付成功率？

小 Y：

我会在代码里打 Log，使用 SLF4J + Logback，写 JSON 日志，然后扔到 ELK；

再用 Micrometer 打一些指标，比如订单总数、成功数；Prometheus 抓一下，用 Grafana 画图；

出了问题就在 Kibana 里面搜一下日志……

Z 经理：

大方向还可以，但缺少一些关键指标和报警的设计，解析里会细讲。

问题 5：如何用 Docker + Kubernetes 部署这些微服务？

Z 经理：

最后，我们要把这些服务部署到 Kubernetes。

你会怎么做？大致流程说一下就行：从构建镜像到上 K8s。

小 Y：

我一般这么干：

  • 用 Maven 打包成 jar；
  • 写个 Dockerfile：FROM eclipse-temurin:17-jre，然后 COPY app.jar 进去；
  • docker build 构建镜像，推到镜像仓库；
  • K8s 那边写个 Deployment 和 Service YAML，kubectl apply -f；
  • 再配个 Ingress 对外暴露。

至于 HPA、资源限制、灰度发布……我还……还在学习中。

Z 经理：

至少跑通了基本流程。

第三轮：AI 智能客服、RAG 与 Agent（偏复杂，小 Y 开始露馅）

主题：用 RAG + 向量数据库 + Agent 做本地生活平台「智能客服系统」，支持问订单、问退款、问商家信息等。

问题 1：如何给本地生活平台做一个 RAG 智能客服？

Z 经理：

我们想做「智能客服」：

  • 用户可以用自然语言咨询：订单状态、退款规则、某商家信息、平台优惠政策等；
  • 背后我们有文档：帮助中心、商家协议、FAQ、运营公告等；
  • 想用 RAG + 向量数据库（比如 Milvus/Chroma/Redis）做检索增强生成。

你大致会怎么设计这套系统？

小 Y：

嗯……RAG……

我知道大概是：先把文档 Embedding 一下，放到向量数据库里，然后用户问问题的时候再搜出来，给大模型看看，它就能回答了。

至于流程嘛，就是：

  • 文档加载，然后拆块，然后向量化；
  • 存；
  • 查；
  • 回答；

差不多这样吧。

Z 经理：

方向没错，但非常笼统，细节可用性会出大问题，后面解析里我会从工程实践角度详细拆开讲。

问题 2：Spring AI / Agentic RAG 在服务端如何落地？

Z 经理：

如果我们用 Spring AI 来封装大模型调用，再配合 Agent 机制（工具调用、工作流），

比如：

  • 用户问「帮我查一下昨天那笔 58 元汉堡订单是否已经退款到账？」
  • Agent 需要：先识别意图，再调用订单查询工具，再调用支付工具，最后综合解释给用户。

你会如何在后端设计这样的 Agent 体系？

小 Y：

这个嘛……Agent 我知道，是那种智能代理，可以调用工具啥的。

我觉得就是写一些工具函数，Agent 自动决定调哪个；

Spring AI 里应该有一些 starter 可以用，然后把向量数据库接进来……

具体怎么做，我，我还没在生产上搞过……

Z 经理：

嗯，确实没落过地。

问题 3：如何控制 AI 幻觉（Hallucination），避免乱回答？

Z 经理：

大模型有「幻觉」问题，可能一本正经地胡说八道。

对于「订单状态、退款金额、支付结果」这种强一致性信息，如果 AI 胡说就会事故。

你会从哪些层面降低幻觉？

小 Y：

这我也看过点文章：

  • 可以在 Prompt 里告诉模型不要瞎编；
  • 然后让它先说「我不确定」之类的；

实在不行就让它少说点……

Z 经理：

这就比较危险了，不能只靠提示词。

问题 4：聊天会话内存与多轮上下文

Z 经理：

用户和客服是多轮对话：

  • 第一轮：我昨天几点下的 XX 商家的订单？
  • 第二轮：那这单现在什么状态？

你怎么在后端管理 会话内存 和上下文，让模型在第二轮能明白「这单」指的就是上一轮那笔订单？

小 Y：

我觉得可以把用户最近几轮对话放在 Redis 或数据库里，然后每次请求的时候把最近几条对话拼一起发给模型。

至于怎么裁剪、怎么选，我一般就截个前几条……

Z 经理：

大致思路对，但生产里还需要更精细的对话存档、检索和隐私控制。

问题 5：AI 与业务服务的边界与风控

Z 经理：

最后一个问题：

  • 订单创建、支付扣款、发起退款，这些是有强安全要求的。
  • 我们让 AI 来辅助用户，但不能让 AI 直接「决定」钱怎么走。

你觉得在架构上，AI 模块和 Java 业务服务之间应该怎么划边界？

小 Y：

AI 听起来挺智能的，要不就让它自动搞定？

比如用户说「帮我退款」，AI 直接帮他调订单服务退款 API，这不是很方便吗？

当然，也可以加个确认什么的……

Z 经理：

如果真这么干，风控部门会第一时间找你喝茶。

面试结束语

Z 经理：

好，今天就到这里。

你在 Spring Boot、基础 Web、简单微服务这块还可以； 在分布式一致性、安全、AI 落地方面还需要补课。

我们会综合评估后通知你结果，你先回去等通知吧。

小 Y：

嗯……好的，那我就……等你们好消息……

面试题详细解析（给小白看的系统梳理）

下面是对上面所有问题的 系统解析，即使你是 Java 小白，也可以顺着业务场景理解一遍。

一、Spring Boot + REST + Swagger：商家查询接口

1. 技术点涉及：

  • Java 8/11/17
  • Spring Boot, Spring Web, Spring MVC
  • RESTful API 设计
  • Swagger / OpenAPI（比如 springdoc-openapi）
  • Maven

2. 业务场景：

  • 本地生活平台中，前端 App 需要展示商家详情：店名、地址、营业状态、评分等。
  • 后端需要提供一个稳定、标准化的 HTTP 接口。

3. 基本代码结构示例：

@RestController
@RequestMapping("/api/merchants")
public class MerchantController {

    private final MerchantService merchantService;

    public MerchantController(MerchantService merchantService) {
        this.merchantService = merchantService;
    }

    @Operation(summary = "根据ID查询商家详情")
    @GetMapping("/{id}")
    public MerchantDTO getMerchant(@PathVariable Long id) {
        return merchantService.getMerchantById(id);
    }
}

4. Swagger/OpenAPI 使用：

  • 引入依赖（以 springdoc-openapi 为例）：
<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.5.0</version>
</dependency>
  • 启动后访问 /swagger-ui/index.html 即可看到自动生成的文档。
  • 优点：前端、测试、运营都可以直接看接口说明，减少沟通成本。

二、MySQL + MyBatis：商家数据访问

1. 技术点：

  • MySQL / PostgreSQL
  • MyBatis / MyBatis-Plus
  • HikariCP 连接池

2. 表设计（示例）：

CREATE TABLE merchant (
    id          BIGINT PRIMARY KEY,
    name        VARCHAR(128) NOT NULL,
    address     VARCHAR(256),
    status      TINYINT NOT NULL,
    created_at  DATETIME,
    updated_at  DATETIME
);
CREATE INDEX idx_merchant_status ON merchant(status);

3. Mapper 示例（MyBatis-Plus）：

@Mapper
public interface MerchantMapper extends BaseMapper<MerchantDO> {
}

4. Service 示例：

@Service
public class MerchantServiceImpl implements MerchantService {

    private final MerchantMapper merchantMapper;

    public MerchantServiceImpl(MerchantMapper merchantMapper) {
        this.merchantMapper = merchantMapper;
    }

    @Override
    public MerchantDTO getMerchantById(Long id) {
        MerchantDO merchant = merchantMapper.selectById(id);
        if (merchant == null) {
            throw new NotFoundException("merchant not found");
        }
        return MerchantConverter.toDTO(merchant);
    }
}

三、Redis 缓存：避免数据库被打爆

1. 技术点：

  • Redis
  • Spring Data Redis / Lettuce
  • Spring Cache

2. 业务场景：

  • 热门商家详情访问非常频繁（比如大牌餐厅），如果每次都查数据库，压力会很大。

3. 基本缓存策略：

  • Key 设计：merchant:{id}
  • Value：JSON 或序列化后的对象
  • 过期时间：例如 30 分钟

4. 缓存穿透 / 击穿 / 雪崩：

  • 穿透：大量请求访问不存在的数据（id 无效）；
    • 解决：对不存在的 id 也缓存一个空值，短过期；或使用布隆过滤器。
  • 击穿：某个热点 key 刚好过期，大量请求同时打到 DB；
    • 解决：互斥锁 + 逻辑过期；或者使用 @Cacheable + sync=true 等策略。
  • 雪崩：大量 key 同时过期，DB 瞬间高压；
    • 解决：过期时间加随机值、分散失效时间；多级限流熔断（Resilience4j）。

5. 简单代码示例：

@Service
public class MerchantCacheService {

    private final StringRedisTemplate redisTemplate;

    public MerchantCacheService(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public MerchantDTO getMerchantCached(Long id) {
        String key = "merchant:" + id;
        String cache = redisTemplate.opsForValue().get(key);
        if (cache != null) {
            return JSON.parseObject(cache, MerchantDTO.class);
        }
        // 这里正常应该加锁防击穿，演示略
        MerchantDTO merchant = loadFromDB(id);
        if (merchant == null) {
            // 防穿透：缓存空值
            redisTemplate.opsForValue().set(key, "", 5, TimeUnit.MINUTES);
            return null;
        }
        redisTemplate.opsForValue().set(key, JSON.toJSONString(merchant), 30, TimeUnit.MINUTES);
        return merchant;
    }
}

四、JUnit 5 + Mockito：服务层单元测试

1. 技术点：

  • JUnit 5
  • Mockito / AssertJ
  • Spring Boot Test

2. 典型测试代码：

@ExtendWith(MockitoExtension.class)
class MerchantServiceTest {

    @Mock
    MerchantMapper merchantMapper;

    @InjectMocks
    MerchantServiceImpl merchantService;

    @Test
    void testGetMerchantById() {
        MerchantDO mock = new MerchantDO();
        mock.setId(1L);
        mock.setName("Hello Burger");

        when(merchantMapper.selectById(1L)).thenReturn(mock);

        MerchantDTO dto = merchantService.getMerchantById(1L);

        assertEquals(1L, dto.getId());
        assertEquals("Hello Burger", dto.getName());
    }
}

好处：

  • 代码更可靠，避免线上简单 bug；
  • 方便重构，跑一遍测试就知道哪里坏了。

五、微服务拆分：订单、支付、风控

1. 技术点：

  • Spring Cloud（Gateway、OpenFeign、Eureka/Consul、Config）
  • gRPC / REST
  • Dubbo（在一些公司仍大量使用）
  • Resilience4j（限流、熔断）

2. 典型服务拆分：

  • user-service：用户信息、会员等级
  • merchant-service：商家资料、门店
  • order-service：订单创建、状态流转
  • payment-service：支付下单、支付回调
  • risk-service：风控评分、风控策略
  • notification-service：短信、Push、站内信

3. 服务边界的关键点：

  • 一个服务有清晰的业务职责；
  • 服务之间通过 API 或消息队列交互；
  • 尽量避免多服务同时写同一块核心数据。

六、Kafka 解耦订单与风控

1. 技术点：

  • Kafka / RabbitMQ / Pulsar
  • Spring Kafka
  • 消息幂等性

2. 业务流程：

  • 用户创建订单 → order-service 写入 DB → 发送 order-created 消息到 Kafka；
  • risk-service 订阅该 Topic，做风险评估；
  • 根据风险结果，可以标记订单需要审核或直接通过。

3. 消息可靠性的关键点：

  • 生产端：
    • acks=all，retries 合理配置；
    • 事务消息 或者“先写 DB，再发消息”（Outbox 模式）。
  • 消费端：
    • 手动提交 offset；
    • 消费逻辑幂等（比如基于订单号去重）。

七、Spring Security + JWT：支付接口安全

1. 技术点：

  • Spring Security
  • JWT（JSON Web Token）
  • OAuth2 / OpenID Connect
  • Keycloak（统一身份认证）

2. 基本思路：

  • 登录：用户名密码 → 校验通过 → 签发 JWT（内含用户 ID、角色等）；
  • 调用：前端在 HTTP Header 里带上 Authorization: Bearer <token>；
  • 后端过滤器解析 JWT，构建 SecurityContext，完成鉴权。

3. 支付接口的额外安全措施：

  • API 签名（避免参数被中间人篡改）；
  • 防重放（timestamp + nonce + 过期时间）；
  • 双因子校验（比如高金额时要求短信验证码）；
  • 幂等（防止用户多次点击造成重复支付）。

八、日志与监控：ELK + Prometheus + Grafana

1. 技术点：

  • 日志：SLF4J + Logback / Log4j2
  • ELK Stack：Elasticsearch, Logstash, Kibana
  • 指标：Micrometer, Prometheus, Grafana
  • 链路追踪：Sleuth, Zipkin, Jaeger

2. 业务指标示例：

  • 支付请求总数
  • 支付成功数、失败数
  • 成功率（成功数 / 总数）
  • 支付平均耗时
  • 各支付渠道错误分布

3. 监控实践：

  • 使用 Micrometer 暴露自定义指标：
Counter paymentSuccess = Counter
    .builder("payment_success_total")
    .tag("channel", "alipay")
    .register(meterRegistry);
  • Prometheus 抓取这些指标；
  • 在 Grafana 中配置仪表盘和告警规则（如支付成功率低于 97% 报警）。

九、Docker + Kubernetes：微服务部署

1. 技术点：

  • Docker / Containerd
  • Kubernetes（Deployment、Service、Ingress、ConfigMap、Secret）
  • GitLab CI / GitHub Actions / Jenkins CI/CD

2.典型流程：

  • 使用 Maven 打包 Spring Boot 应用为 jar；
  • 用 Docker 构建镜像，推送到私有镜像仓库（Harbor 等）；
  • K8s 中编写 Deployment & Service YAML；
  • 使用 HPA（Horizontal Pod Autoscaler）根据 CPU/QPS 自动扩容；
  • 使用 ConfigMap/Secret 管理配置和密钥。

十、RAG 智能客服：从文档到问答

1. 关键概念：

  • RAG（Retrieval-Augmented Generation，检索增强生成）
  • 向量化（Embedding）：把文本变成向量
  • 向量数据库：Milvus、Chroma、Redis、Pinecone 等
  • 语义检索：根据意思找文档，而不是只按关键词

2. 业务场景：

  • 文档：帮助中心、商家协议、运营公告；
  • 用户问题：
    • 「平台的退款规则是什么？」
    • 「某某商家支持开发票吗？」

3. RAG 典型流程：

  1. 文档加载：PDF、Markdown、HTML、数据库等；
  2. 分段（Chunking）：按段落或长度切片；
  3. 向量化：调用 Embedding 模型（OpenAI、Ollama 等）；
  4. 存储：把向量和原文一起存入向量数据库；
  5. 查询：用户问问题时，对问题向量化并检索最相似的若干片段；
  6. 生成：把相关片段 + 用户问题一起作为 Prompt 提给大模型，生成答案。

4. 控制幻觉的关键点：

  • 明确告诉模型「必须以检索到的内容为准，不要编造」；
  • 将检索到的文档片段原文返回给前端，让用户可见「出处」；
  • 对订单金额、支付结果这类强一致性信息：
    • 不要让模型自己算，而是调用后端接口查询真实数据；
    • 模型只负责解释结果，而不是决定结果。

十一、Spring AI + Agent：工具调用与工作流

1. 技术点：

  • Spring AI（统一大模型客户端）
  • Agent（智能代理）：能根据目标自动选择工具调用；
  • 工具执行框架：REST/gRPC 调用现有 Java 服务；
  • 工作流：复杂任务拆分为多步。

2. 订单查询例子：

  • 用户：

    帮我查一下昨天那笔 58 元汉堡订单是否已经退款到账？

  • Agent 的思路：

    1. NLU：识别意图是「订单退款状态查询」；
    2. 工具调用 1：调用 order-service 的「按用户 + 时间 + 金额」查订单；
    3. 工具调用 2：调用 payment-service 查询退款单状态；
    4. 整理结果并用自然语言回答。

  • Spring AI 的角色：

    • 封装 LLM 调用；
    • 根据模型的“工具调用计划”触发后端的 Java 方法或 HTTP 接口；
    • 管理对话状态（会话内存）。

十二、聊天会话内存与上下文管理

1. 技术点：

  • Redis / 数据库存储对话记录
  • 会话 ID（sessionId）
  • 上下文裁剪和摘要

2. 典型做法：

  • 每一轮对话保存为一条记录：用户问题、AI 回答、时间戳；
  • 每次请求时，从最近 N 条对话里挑出最相关的几条拼到 Prompt 中；
  • 超长对话可以定期做「摘要」，节省 Token；
  • 对敏感信息（手机号、身份证）做脱敏或不入库。

十三、AI 与业务服务的边界与风控

1. 原则：

  • AI 负责「理解和表述」；
  • Java 微服务负责「真实的数据和交易逻辑」。

2. 实践建议：

  • 所有真金白银的操作（支付、退款、优惠券发放）：
    • 必须走传统的 API 流程：鉴权、权限校验、幂等、防重放；
    • AI 最多帮用户填好参数，让用户点击确认。
  • AI 不能直接绕开风控、ACL 等安全机制。

总结：从小 Y 的面试到你的成长路径

这场面试里，小 Y：

  • 对 Java 基础 + Spring Boot + Web + MyBatis + Redis + JUnit 还算熟；
  • 对 微服务拆分、Kafka 消息、支付安全、监控 只停留在关键词级别；
  • 对 RAG、向量数据库、Agent、AI 幻觉控制、会话内存 几乎没有工程实践经验。

如果你也处在类似阶段，可以按下面路径学习：

  1. 先打牢：Java SE、JVM 基础、集合、并发；
  2. 再熟练：Spring Boot、Spring MVC、Spring Data、Redis、Kafka；
  3. 进阶：Spring Cloud、分布式事务、监控与日志、Docker + Kubernetes；
  4. 拓展：Spring AI、RAG、向量数据库、Agent 工作流，理解 AI 如何安全地嵌入业务系统。

当你能把上面故事里的所有问题都说得条理清晰，并且能写出相应代码与架构图时，你已经非常接近大厂 Java 高级工程师的门槛了。

# 微服务
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

桌游玩家招募！全球首款 AI 主题桌游《Talk With》线下开玩丨北京 AI 原点社区 Party Nights 见！

在中关村论坛人工智能主题日期间，为展现海淀人工智能生态氛围、传播原点社区品牌价值。3月25日-29日在AI原点社区举办「原点Party Nights」系列活动。紧扣「强社交、重体验、深联动」的活动调性，定位为AI青年会客厅和思想碰撞实验场，整合中关村AI原点社区社交空间、赛博空间、展示空间，邀请主论坛嘉宾、AI行业大咖、AI原生青年共聚原点社区，策划开展「嗨点小圆桌」播客、AI创新工作坊、原点派对

avatar AtomGit开源社区

这份榜单够用！高效论文写作全流程AI论文工具推荐（2026 最新）

论文写作全流程可拆解为文献调研→选题/开题→大纲/初稿→文献综述→降重/去AI味→润色/格式→查重/投稿七大环节，以下工具按环节精准匹配，兼顾中文适配、降重能力、去AI痕迹、学术合

avatar AtomGit开源社区

SpringBoot整合Email 邮件发送详解

通过上述步骤，我们成功在SpringBoot项目中整合了Email服务，实现了普通邮件、HTML邮件、含静态资源邮件以及带附件邮件的发送。这不仅提升了应用的功能性，也增强了与用户的互动。希望本文能够帮助到需要在项目中集成邮件服务的开发者。版权声明：本博客内容为原创，转载请保留原文链接及作者信息。参考文章SpringBoot整合Email 邮件发送-CSDN博客SpringBoot整合邮箱发送邮件

avatar AtomGit开源社区