"你对最近的技术趋势有什么了解?"——这道题区分"只会CRUD"和"有技术视野"的候选人

1. Java 生态最新趋势

1.1 Java 版本演进:从 Java 21 LTS 到 Java 25

趋势说明

Java 的版本发布节奏已经进入"每 6 个月一个版本"的快车道。Java 21(2023.09 LTS)是继 Java 17 之后最重要的 LTS 版本,引入了 Virtual Threads(虚拟线程)、Record Patterns、Pattern Matching for switch、Sequenced Collections 等重量级特性。到 2025-2026 年,Java 25 将成为最新 LTS,而业界主流正在从 Java 8/11 大规模迁移到 Java 21+。

版本发布时间类型核心新特性
Java 172021.09LTSSealed Class、Records、Pattern Matching (preview)
Java 212023.09LTSVirtual Threads、Record Patterns、Pattern Matching (final)、Sequenced Collections、String Templates (preview)
Java 232024.09非LTSMarkdown in Javadoc、Module Import (preview)、Flexible Constructor Bodies (preview)
Java 252025.09LTSScoped Values (final)、Structured Concurrency (final)、Stream Gatherers (final)、Value Objects (preview)

Virtual Threads(虚拟线程)—— 最值得关注的变化

虚拟线程是 Project Loom 的交付成果,它改变了 Java 的并发编程模型:

// 传统线程池方式(Platform Thread)
ExecutorService executor = Executors.newFixedThreadPool(200);
executor.submit(() -> {
    // 每个请求占用一个 OS 线程,受限于 OS 线程数量
});

// 虚拟线程方式(Virtual Thread)
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        // 数百万虚拟线程共享少量 OS 线程,几乎没有上下文切换开销
    });
}

// 或者更简单:直接创建虚拟线程
Thread.startVirtualThread(() -> {
    // 这段代码运行在虚拟线程上
});

虚拟线程的核心原理是 M:N 调度 —— 大量 Java 虚拟线程(M)被映射到少量 Carrier Thread(N,通常是 OS 线程)上。当虚拟线程执行 I/O 操作(如数据库查询、HTTP 调用)时,它会自动从 Carrier Thread 上 yield 下来,Carrier Thread 再去执行另一个虚拟线程,从而实现了极高的吞吐量。

面试关联

面试场景可展示的技术深度
"你了解虚拟线程吗?"解释 M:N 调度模型、与 WebFlux 响应式编程的区别
"虚拟线程能替代线程池吗?"分析 CPU 密集型 vs I/O 密集型场景的不同适用性
"虚拟线程有坑吗?"讨论 Pinned 问题(synchronized 关键字)、ThreadLocal 滥用
"你们项目在用 Java 21 吗?"说明迁移策略:先从新项目开始,逐步替换 Web 服务器

标准话术

"我们在今年年初将核心服务的 JDK 从 Java 11 升级到了 Java 21。最主要的原因是 Virtual Threads 让我们在处理大量 I/O 密集型请求时,不需要再用 WebFlux 那种回调式的响应式编程。用虚拟线程配合 Tomcat(从 10 版本开始支持虚拟线程),代码就是普通的同步阻塞风格,但吞吐量提升了大约 3-5 倍。不过我们也踩了一些坑,比如虚拟线程中用了 synchronized 关键字会导致 pinned 问题,需要替换成 ReentrantLock。另外 ThreadLocal 的用法也要收敛,因为虚拟线程数量巨大,ThreadLocal 的内存泄漏问题会更严重。"

1.2 Spring Boot 3.x + Spring Framework 6 的变革

趋势说明

Spring Boot 3.x(2022.11 发布)是一次架构级的大版本升级:

变更项Spring Boot 2.xSpring Boot 3.x
Java 基线Java 8+Java 17+(最低要求)
包名javax.*jakarta.*(Jakarta EE 9/10)
GraalVM实验性支持生产级 Native Image 支持
虚拟线程不支持内置支持(通过 spring.threads.virtual.enabled=true)
可观测性MicrometerMicrometer Tracing + OpenTelemetry 集成
安全Spring Security 5Spring Security 6(移除废弃 API)

GraalVM Native Image 与 AOT 编译

Spring Boot 3.x 最重要的能力提升是 Ahead-of-Time (AOT) 编译:

<!-- Spring Boot 3.x + GraalVM Native Build -->
<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
</plugin>
# 构建原生镜像(启动时间从秒级降到毫秒级)
mvn -Pnative native:compile

# 启动一个 Spring Boot 原生应用
./target/my-application

AOT 编译的优势与代价:

维度传统 JVM 部署Native Image
启动时间5-10 秒< 100ms
内存占用200-500MB20-50MB
峰值性能高(JIT 优化)略低(无 JIT,但即时启动)
反射支持全量支持需要配置反射 hint
构建时间即时2-5 分钟(慢)
适合场景长运行服务Serverless / 短生命周期应用

面试关联

面试官问 Spring Boot 3 迁移,考察的是你对 Jakarta EE 命名空间变更、废弃 API 的清理、配置兼容性 的实操经验,而不是单纯背版本号。

标准话术

"我们团队去年完成了从 Spring Boot 2.x 到 3.x 的迁移。最大的工作量不是功能改造,而是 javax 到 jakarta 的包名替换——虽然是全局替换,但涉及第三方依赖的兼容性检查,花了不少时间。另外我们评估了 GraalVM Native Image,最终决定在 两个场景 使用:一个是 CI/CD 流水线中的集成测试环境,用原生镜像把启动时间从 10 秒降到 50ms,流水线快了非常多;另一个是公司内部的轻量级 Webhook 服务,用了原生镜像部署成 Serverless 函数。但核心业务服务还没有上原生镜像,因为反射和动态代理的使用太普遍了,编译期的配置成本太高。"

1.3 Spring AI 框架的崛起

趋势说明

Spring AI 是 Spring 生态官方出品的 AI 集成框架(2023 年底启动,2024 年发布正式版),定位是成为 Java 生态整合 LLM 的标准方案。它在 Spring 生态中的位置,类比于 Spring JDBC / Spring Data 对数据库的抽象。

┌──────────────────────────────────────────────┐
│              你的业务代码                       │
├──────────────────────────────────────────────┤
│           Spring AI API 抽象层                 │
│  ChatClient / EmbeddingModel / VectorStore    │
├──────────────────────────────────────────────┤
│  OpenAI  │  Ollama  │ 通义千问 │  DeepSeek   │
│  (云API) │  (本地)  │  (阿里云)│  (国产模型)  │
└──────────────────────────────────────────────┘
// Spring AI 最简单的用法 —— 调用 LLM
@Service
public class AIService {

    private final ChatClient chatClient;

    // Spring AI 自动注入 ChatClient
    public AIService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String ask(String question) {
        return chatClient.prompt()
                .user(question)
                .call()
                .content();
    }
}

// 结构化输出 —— LLM 返回 Java 对象
public record ProductInfo(String name, String category, double price) {}

ProductInfo product = chatClient.prompt()
        .user("提取商品信息:" + text)
        .call()
        .entity(ProductInfo.class);  // 自动解析 LLM 返回为 Java 对象

面试关联

问题回答要点
"你怎么看 Spring AI?"定位是 AI 集成标准层,类比 Spring JDBC 对数据库的抽象
"Spring AI 的优缺点?"抽象了主流 LLM API,但最新模型特性可能有延迟
"你们项目在用什么 AI 框架?"对比 LangChain4j 和 Spring AI 的差异

标准话术

"我们公司从去年开始探索 LLM 在业务中的应用,最开始是用 Python 写 AI 服务,但和 Java 后端的集成成本很高。后来试了 Spring AI,发现它确实解决了 Java 项目接入 LLM 的痛点。比如用它做 智能客服的意图识别,原来我们需要单独部署一个 Python 服务,通过 HTTP 调用,现在直接在 Spring Boot 服务里注入一个 ChatClient 就可以了。Spring AI 抽象了各大模型厂商的 API 差异,切换模型只需要改配置,不需要改代码。当然,对于复杂的 RAG 流程、多步 Agent 编排,Spring AI 生态还不够成熟,我们会配合 LangChain4j 一起用。"

1.4 虚拟线程对后端性能的实际影响

趋势说明

虚拟线程自 Java 21 正式发布以来,已经在业界得到广泛验证。各大厂(阿里、美团、字节、Netflix)都在积极推进 Java 21+ 的升级,主要原因就是虚拟线程带来的 吞吐量大幅提升 和 代码简化。

性能对比数据(基于业界公开 benchmark)

场景传统线程池虚拟线程提升幅度
Tomcat 默认线程数200不需要配置无瓶颈限制
单机并发连接数500-2000(受限于 OS 线程)数万-数十万10x-100x
线程上下文切换高(OS 级别)极低(用户态)数量级降低
内存占用/线程~1MB~2KB500x 降低
# Spring Boot 3.x + 虚拟线程的配置
spring:
  threads:
    virtual:
      enabled: true  # 一键开启虚拟线程
  # 不需要再配置 server.tomcat.threads.max

注意:虚拟线程并非万能。对于 CPU 密集型 计算(图像处理、加解密、大量计算),虚拟线程没有优势,甚至因为调度开销略有劣势。它的核心价值在于 I/O 密集型 场景(数据库操作、RPC 调用、HTTP 请求)。

为什么大厂都在迁移到 Java 21+

  1. 成本降低:同样 QPS 下,需要的机器数减少
  2. 代码简化:不再需要异步回调(CompletableFuture 的链式调用)、不再需要 WebFlux 的响应式编程
  3. 运维友好:传统线程池调优是黑艺术,虚拟线程几乎不需要调优
  4. 生态成熟:Tomcat 10+、Jetty 12+、Netty 都已完成适配

面试关联

面试官问虚拟线程,真正的考察点是:"年轻人,你搞清楚了它解决什么、不解决什么吗?"

标准话术

"虚拟线程是我们升级 Java 21 后感受最明显的变化。以前做高并发接口,需要调优线程池参数、用 CompletableFuture 做异步编排、甚至考虑 WebFlux,代码复杂度很高。用了虚拟线程后,代码写回同步风格,但吞吐量反而上去了。不过我们也发现了几个需要注意的地方:一是 synchronized 关键字 会导致虚拟线程 pinned 住 carrier thread,要用 ReentrantLock 替代;二是 线程池隔离 的策略要调整,以前不同业务用不同线程池隔离,虚拟线程下更建议用信号量(Semaphore)来做限流;三是 ThreaLocal 泄漏 的问题更严峻了,因为虚拟线程数量很大,用完一定要 remove。"


2. 云原生深化

2.1 K8s 成为标配,Serverless / FaaS 兴起

趋势说明

Kubernetes 已经从一个"新潮技术"变成了云原生时代的 "操作系统"。到 2025-2026 年,K8s 是后端开发的事实标准,不再是加分项,而是 必选项。与此同时,Serverless 和 FaaS 正在从"玩具"走向生产环境。

Serverless 的分层演进

传统部署 → 容器化 → K8s 托管 → Serverless
                                           
    VMware    Docker     K8s + Helm    Knative / AWS Lambda
    手动部署    Docker     Deployment   自动伸缩到零
    物理机     Compose    HPA 自动扩缩  按调用次数计费
部署方式运维成本资源利用率扩缩容速度适合场景
传统物理机极高低(20-40%)分钟级遗留系统
虚拟机高中(40-60%)分钟级传统企业
Docker + K8s中高(60-80%)秒级主流方案
Serverless极低极高(按需付费)毫秒级事件驱动/批处理

Spring Boot + Serverless 实践

// Spring Cloud Function + AWS Lambda —— Serverless 化的 Spring 应用
@SpringBootApplication
public class OrderFunctionApplication {

    @Bean
    public Function<String, String> processOrder() {
        return orderId -> {
            // 这个函数可以部署到 AWS Lambda / 阿里云函数计算
            return orderService.process(orderId);
        };
    }
}
# Knative Serving 配置 —— 自动伸缩到零
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: order-service
spec:
  template:
    spec:
      containers:
        - image: registry.example.com/order-service:latest
      # 缩容到零,有请求时冷启动
      # 配合 Spring Boot AOT 原生镜像,冷启动 < 100ms

面试关联

问题回答要点
"你们公司 K8s 用得多深?"不只是部署,还要用 Helm、Operator、Service Mesh
"Serverless 适合什么场景?"短生命周期任务、事件驱动、定时任务、波动大的业务
"Spring Boot 在 K8s 上的注意事项?"健康检查、优雅关闭、配置外化、日志采集

标准话术

"K8s 在我们公司已经用了两年多,现在新服务全部跑在 K8s 上。我们的实践深度包括:用 Helm Chart 管理部署模板、用 ArgoCD 做 GitOps 的持续交付、用 K8s Operator 管理有状态应用(比如数据库中间件)。对于 Serverless,我们用了 Knative 来处理一些低频的批处理任务,比如每天一次的报表生成、消息推送——这些服务平时没有流量,缩容到零,节省了不少资源。但核心 API 服务还是用常规 Deployment,避免冷启动带来的延迟。"

2.2 Service Mesh(Istio)的落地现状

趋势说明

Service Mesh 从"概念热"走向了"务实落地"。Istio 已经统治了 Service Mesh 市场,但落地现状是:大厂在用,中型公司在评估,小公司先放放。

Service Mesh 的核心价值

传统微服务通信:              Service Mesh 方式:
┌─────────────┐              ┌─────────────┐
│   UserService│              │   UserService│
│   + OpenFeign│              │   + OpenFeign│ (本地通信)
│   + Sentinel │              └─────────────┘
│   + 熔断逻辑 │                    │ proxy
│   + 负载均衡 │              ┌─────▼──────┐
│   + 超时重试 │              │ Envoy Sidecar│
└─────────────┘              │ (流量治理逻辑)│
                              └─────┬──────┘
                                    │ mTLS
                              ┌─────▼──────┐
                              │ Envoy Sidecar│
                              └─────┬──────┘
                              ┌─────▼──────┐
                              │ OrderService│
                              └─────────────┘

Istio 的实际收益 vs. 成本

维度收益成本
流量管理灰度发布、A/B 测试、流量镜像开箱即用增加运维复杂度
安全自动 mTLS、细粒度授权策略CA 证书管理
可观测性自动采集 Metrics/Traces/LogsSidecar 消耗额外资源
网络延迟无每跳增加 1-3ms 延迟

面试关联

面试官问 Service Mesh,主要看你对 "什么时候该用、什么时候不该用" 的判断力,而不是背概念。

标准话术

"我们团队在评估过 Istio 之后,目前的决策是:生产环境暂时不上。主要原因是我们的服务规模只有 30+ 个,流量治理完全可以用 Spring Cloud Gateway + Sentinel 来满足,引入 Istio 带来的运维成本(运维同学要学习 Istio、管理 Sidecar 注入、排查 Envoy 问题)超过了它的收益。如果以后服务增长到 100+ 个,服务间的流量管控变得复杂,我们会重新考虑 Istio。不过在公司的 测试环境 里,我们用 Istio 做灰度发布和流量镜像,体验是不错的。"

2.3 eBPF 在可观测性中的革命性应用

趋势说明

eBPF(Extended Berkeley Packet Filter)是 Linux 内核的一项革命性技术,允许在不修改内核代码、不加载内核模块的情况下,安全地运行沙箱化程序。在可观测性领域,eBPF 正在颠覆传统的埋点方式。

传统可观测性 vs. eBPF 可观测性

维度传统方式eBPF 方式
数据采集应用代码埋点 + Agent内核层面自动采集
对应用的影响需要修改代码/配置零侵入,无需修改应用
覆盖范围只能覆盖埋点过的服务覆盖所有进程(包括 Sidecar)
性能开销中(取决于埋点密度)极低(内核原生)
延迟精度毫秒级微秒级

eBPF 在可观测性中的典型应用

┌───────────── eBPF 可观测性全景 ─────────────┐
│                                               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │ 网络监控  │  │ 性能分析  │  │ 安全审计  │    │
│  │ (Pixie)  │  │ (BCC)   │  │ (Falco)  │    │
│  ├──────────┤  ├──────────┤  ├──────────┤    │
│  │ HTTP 请求 │  │ CPU 热点 │  │ 系统调用  │    │
│  │ 延迟分布  │  │ 内存分配 │  │ 容器逃逸  │    │
│  │ TCP 重传 │  │ 磁盘 I/O │  │ 特权提升  │    │
│  └──────────┘  └──────────┘  └──────────┘    │
│                                               │
│         底层:eBPF 虚拟机在内核中运行            │
└───────────────────────────────────────────────┘

面试关联

eBPF 是一个"拔高层级"的话题。面试中提及它,可以展示你对基础设施层技术的了解深度。

标准话术

"我对 eBPF 在可观测性中的落地比较关注。目前我们在用 Pixie(基于 eBPF 的可观测性平台)做测试环境的无侵入式监控。传统的 APM(如 SkyWalking)需要在应用里埋 Agent,而 Pixie 通过 eBPF 自动捕获内核级别的 HTTP 请求数据,完全不需要改动应用代码。对于需要 全量采集 的场景——而不是采样——eBPF 的方案非常有吸引力。不过生产环境我们还没有上,主要是因为数据量太大了,存储成本需要评估。"

2.4 多运行时架构(Dapr)的概念

趋势说明

Dapr(Distributed Application Runtime)是微软推出的多运行时架构实现。它的核心思想是:把分布式应用中的通用能力(服务调用、状态管理、发布订阅、绑定、可观测性)从应用代码中抽离到一个独立的 Sidecar 进程中。

传统微服务架构:
┌───────────────────┐
│  服务代码           │
│  + Nacos SDK       │  ← 注册发现
│  + Redis SDK       │  ← 状态管理
│  + RocketMQ SDK    │  ← 消息队列
│  + Sentinel SDK    │  ← 限流熔断
│  + 配置管理 SDK     │  ← 配置中心
└───────────────────┘

Dapr 多运行时架构:
┌───────────────────┐  ┌────────────────────┐
│  服务代码           │  │  Dapr Sidecar       │
│  (纯业务逻辑)       │  │  + Service Invoke   │
│  │ 只关心业务       │  │  + State Store      │
│  │ 通过 HTTP/gRPC  │◄─►│  + Pub/Sub          │
│  │ 调用 Dapr API   │  │  + Bindings         │
└───────────────────┘  │  + 可观测性           │
                        └────────────────────┘
                               │
                    ┌──────────┴──────────┐
                    │   底层基础设施        │
                    │ Redis / K8s / Kafka  │
                    └─────────────────────┘

Dapr 的优势与适用场景

维度Dapr 方式传统方式
语言无关任何语言通过 HTTP 调用 Dapr API需要对应语言的 SDK
可替换性切换基础设施只需改配置需要修改代码
复杂度新增 Sidecar,运维复杂度增加简单直接
延迟多一跳(应用 → Sidecar)直接调用

面试关联

面试中提及 Dapr 可以展示你对 "架构演进方向" 的思考,但要注意 Dapr 在国内的落地还很少,尽量以"了解"和"在关注"的口吻表达。

标准话术

"我关注到 Dapr 代表的多运行时架构是一个值得留意的方向。它的思路是把分布式基础设施的能力从业务代码中剥离出来,让开发只关心业务逻辑。这和我们做微服务时的理想状态是一致的——开发不需要知道用的是 Nacos 还是 Consul,Kafka 还是 RocketMQ。不过目前国内 Dapr 的生态还在早期,生产落地案例较少,我们团队暂时在技术调研阶段。"


3. AI 与大模型的工程落地

3.1 LLM 在企业中的应用场景

趋势说明

2025-2026 年,大语言模型(LLM)已经从"炫技demo"进入企业级工程落地阶段。后端开发人员需要了解 LLM 在真实业务中能做什么、怎么落地、有哪些坑。

企业级 LLM 应用场景矩阵

应用场景技术方案后端整合点ROI 评级
代码生成/辅助GitHub Copilot / 通义灵码 / CodeGeeXIDE 插件,不涉及后端★★★★★
智能客服RAG + 知识库 + Prompt 模板后端提供检索 API★★★★★
文档分析LLM + PDF 解析 + 向量化文档上传、向量存储服务★★★★
自动化测试LLM 生成测试用例、Mock 数据CI/CD 流水线集成★★★★★
代码审查LLM Review 代码变更集成到 Code Review 流程★★★★
数据标注LLM 替代人工标注后端调用 LLM API 做批量标注★★★
风控审核LLM 文本内容审核中间件层注入审核逻辑★★★★
智能报表NL2SQL + LLM后端提供自然语言查询接口★★★

Java 后端整合 LLM 的典型模式

// 模式一:直接调用 LLM API(最简单)
public class SimpleAIService {
    
    private final RestClient restClient;  // Spring Boot 3.2 引入的声明式 HTTP 客户端
    
    public String summarize(String text) {
        return restClient.post()
                .uri("https://api.deepseek.com/v1/chat/completions")
                .body(new ChatRequest("summarize: " + text))
                .retrieve()
                .body(CompletionResponse.class)
                .getContent();
    }
}

// 模式二:通过 Spring AI 抽象层(推荐)
public class StructuredAIService {
    
    private final ChatClient chatClient;
    
    // 提取结构化数据
    public OrderInfo extractOrderInfo(String rawText) {
        return chatClient.prompt()
                .user(u -> u.text("从以下文本中提取订单信息:{text}")
                        .param("text", rawText))
                .call()
                .entity(OrderInfo.class);  // Spring AI 自动将 LLM 输出映射为 Java 对象
    }
}

面试关联

面试问题回答方向
"你们公司在用 AI 做什么?"选择 1-2 个实际落地的场景,不要只说"在探索"
"LLM 生成的内容质量怎么保证?"讨论 Prompt 工程、RAG 增强、人工审核兜底
"LLM 的延迟和成本怎么控制?"缓存策略、模型蒸馏、流式输出、token 预算

标准话术

"我们公司在 LLM 应用上目前有两个落地场景。第一个是 智能客服,用 RAG 架构实现——把产品文档、常见问题 FAQ 向量化存入 Milvus,用户提问后先检索相关文档片段,再和问题一起发给 LLM 生成回答。相比之前的纯关键词匹配,问题的解决率从 60% 提升到了 85%。第二个是 自动化代码审查,在 MR 流水线中集成了一个 LLM 步骤,对 Java 代码做静态安全检测和代码风格检查,虽然不能替代人工审查,但可以提前发现一些明显的问题。成本控制方面,我们用了 多模型策略:简单场景用 DeepSeek(低成本),复杂场景用 GPT-4,并且对所有 LLM 调用结果做了 Redis 缓存,同样的提问直接返回缓存结果。"

3.2 RAG 架构成为企业 AI 标配

趋势说明

RAG(Retrieval-Augmented Generation)已经成为企业落地 LLM 的 首选架构。相比于直接使用 LLM 的原始知识,RAG 通过"检索 + 生成"的组合模式,解决了 LLM 的幻觉问题、知识时效性问题、私有数据保护问题。

┌───────────────── RAG 标准架构 ─────────────────┐
│                                                   │
│  ① 文档处理                                     │
│  PDF / Word / 网页                               │
│      │                                           │
│      ▼                                           │
│  ② 切分 (Chunking)                              │
│  ┌─────────────────┐                            │
│  │ Chunk 1: 300 tokens│  重叠 50 tokens          │
│  │ Chunk 2: 300 tokens│                           │
│  │ Chunk 3: 300 tokens│                           │
│  └────────┬────────┘                            │
│           ▼                                      │
│  ③ 向量化 (Embedding)        ┌──────────────┐   │
│      ┌──────────────────────►│  Embedding    │   │
│      │                       │  模型 (BGE/   │   │
│      │                       │  text2vec)    │   │
│      │                       └──────┬───────┘   │
│      ▼                              ▼            │
│  ④ 存储                       向量 + 原始文本     │
│  ┌────────────┐             ┌────────────┐       │
│  │ 向量数据库  │◄────────────│   原始文本   │      │
│  │ (Milvus)   │             │  (PostgreSQL)│      │
│  └────────────┘             └────────────┘       │
│                                                   │
│  ⑤ 用户提问 → 向量化 → 相似度检索 → Top-K       │
│  ⑥ 检索结果 + 原始问题 → LLM → 生成回答          │
└─────────────────────────────────────────────────┘

RAG 与 Java 项目的结合点

// Java 后端实现 RAG 的核心流程
@Service
public class RagService {

    private final VectorStore vectorStore;  // Spring AI 抽象的向量存储
    private final ChatClient chatClient;

    public String answer(String question) {
        // 1. 检索相关文档
        List<Document> docs = vectorStore.similaritySearch(
                SearchRequest.query(question).withTopK(3));
        
        // 2. 构建带上下文的 Prompt
        String context = docs.stream()
                .map(Document::getContent)
                .collect(Collectors.joining("\n---\n"));

        // 3. 调用 LLM 生成回答
        return chatClient.prompt()
                .system("你是一个客服助手。请基于以下参考文档回答问题。" +
                        "如果参考文档中找不到答案,请明确告知用户。" +
                        "参考文档:\n" + context)
                .user(question)
                .call()
                .content();
    }
}

RAG 的关键技术挑战

挑战解决方案工程要点
检索质量Chunk 策略优化 + Hybrid Search混合使用关键词(ES BM25)和向量检索
上下文窗口Rerank 重排序检索 10 条,Rerank 取 Top-3
知识更新增量更新策略文档更新 → 重新向量化 → 替换旧向量
延迟优化向量 + 缓存双层架构高频问题走缓存,低频问题走 RAG
多轮对话对话历史压缩 + 重写将"它多少钱?"重写为"iPhone 15 多少钱?"

面试关联

面试官问 RAG,考察的是 "你不仅仅是调了一个 API,而是理解了检索和生成的整条链路"。

标准话术

"我们公司的 AI 客服系统就是基于 RAG 架构 实现的。我之前在文件上踩过一些坑:最开始按固定字数 500 字切分,发现一个问题涉及多个知识点时,单一切片的信息不全。后来改成了 语义切分,按 Markdown 标题和段落结构来切,并且加了 50 个 token 的重叠。检索方面,我们做了 混合检索——用 Elasticsearch 做关键词匹配 + 向量数据库做语义检索,再用一个 Rerank 模型给结果打分排序,效果比只用向量检索好了不少。存储方面,我们在 Spring Boot 里集成了 Spring AI + Milvus,整个过程对业务代码的侵入很小。"

3.3 AI Agent / MCP 协议的发展

趋势说明

AI Agent(智能体)是 2025 年最热门的 AI 方向之一。如果说 RAG 是"让 LLM 知道更多",那 Agent 就是 "让 LLM 能做更多"——赋予 LLM 调用工具、执行动作的能力。

MCP(Model Context Protocol)协议

MCP 是 Anthropic 提出的一种开放协议,定义了 LLM 应用与外部工具/数据源的交互标准。类似于 "AI 世界的 USB-C 接口":

传统 LLM 工具调用(百花齐放):
┌──────────┐  自定义格式  ┌──────────┐
│  OpenAI  │────────────→│  Function A │
│  Function│             └──────────┘
│  Calling │  自定义格式  ┌──────────┐
│          │────────────→│  Function B │
└──────────┘             └──────────┘

MCP 协议(统一标准):
┌──────────┐  MCP 协议   ┌─────────────┐
│  MCP     │────────────→│  MCP Server  │
│  Client  │             │  (工具提供方) │
│  (任意   │             │              │
│  LLM应用)│             │  ┌─────────┐  │
│          │             │  │ 数据库   │  │
│          │             │  ├─────────┤  │
│          │             │  │ API     │  │
│          │             │  ├─────────┤  │
│          │             │  │ 文件系统 │  │
│          │             │  └─────────┘  │
└──────────┘             └─────────────┘

Java 后端的 Agent 集成

// 使用 Spring AI 实现一个简单的 Agent
@Component
public class OrderAgent {

    private final ChatClient chatClient;

    @Bean
    public ToolCallback queryOrderTool() {
        return ToolCallbackBuilder.builder()
                .name("queryOrderStatus")
                .description("查询订单状态,参数:订单号 orderId")
                .inputType(String.class)
                .toolFunction(orderId -> {
                    // 调用已有的订单服务
                    return orderService.queryStatus((String) orderId);
                })
                .build();
    }

    public String handle(String userMessage) {
        // Agent 会自动判断是否需要调用工具,并组装最终回答
        return chatClient.prompt()
                .user(userMessage)
                .tools(queryOrderTool())  // 注册工具
                .call()
                .content();
    }
}

面试关联

问题回答要点
"你怎么理解 AI Agent?"Agent = LLM + 记忆 + 规划 + 工具调用
"MCP 协议的价值?"统一工具调用标准,降低 LLM 与工具的集成成本
"Agent 在生产环境落地了吗?"还处于早期,可靠性、安全边界是主要挑战

标准话术

"Agent 是我个人最看好的 AI 应用方向。简单来说,Agent = LLM 的大脑 + 工具的手臂。比如一个智能客服 Agent,不只是回答问题,还能进一步调用查询订单、发起退款、修改地址等接口。我们团队在公司的一个内部工单系统上尝试了 Agent 功能:用户用自然语言描述问题,Agent 自动判断调用哪个 API、填入什么参数、执行什么操作。不过 Agent 的 可靠性 还需要提升——LLM 有可能选择错误的工具或填入错误的参数,我们目前的方案是设置一个 人工确认 环节,关键操作(比如退款)必须人工确认后才执行。MCP 协议我认为是个好方向,如果标准化成熟了,Java 后端暴露的 API 可以统一用 MCP Server 的形式给 AI 应用调用。"

3.4 向量数据库的 Java 整合

趋势说明

向量数据库是 RAG 架构的基石。主流向量数据库包括 Milvus(开源/分布式)、Pinecone(云托管)、Weaviate(开源+GraphQL 接口)、Qdrant(Rust 实现/高性能)。

主流向量数据库对比

特性Milvus 2.xWeaviateQdrantPinecone
部署方式自建/K8s自建/K8s/云自建/K8s/云云托管
索引类型IVF/IVF_PQ/HNSWHNSWHNSW自动化
混合搜索支持支持支持不支持
分布式✓ 成熟✓✓✓
Spring AI 集成✓✓✓✓
Java 客户端✓ 官方✓ 官方✓ 官方✓ REST
场景定位大型系统中小型高性能快速验证
# Spring AI + Milvus 配置
spring:
  ai:
    vectorstore:
      milvus:
        host: ${MILVUS_HOST:localhost}
        port: 19530
        database: default
        collection-name: knowledge_docs
        index-type: IVF_FLAT
        metric-type: COSINE

# Spring AI + Qdrant 配置
spring:
  ai:
    vectorstore:
      qdrant:
        host: ${QDRANT_HOST:localhost}
        port: 6334
        collection-name: docs
// Java 中直接使用 Milvus SDK
@Service
public class VectorSearchService {

    private final MilvusServiceClient milvusClient;

    public List<SearchResult> search(float[] queryVector, int topK) {
        List<String> searchOutputFields = Arrays.asList("doc_id", "content");

        SearchParam param = SearchParam.newBuilder()
                .withCollectionName("knowledge_base")
                .withVectors(Collections.singletonList(queryVector))
                .withVectorFieldName("embedding")
                .withTopK(topK)
                .withParams("{\"nprobe\": 10}")
                .withOutFields(searchOutputFields)
                .build();

        R<SearchResults> response = milvusClient.search(param);
        return parseResults(response.getData());
    }
}

面试关联

面试中聊向量数据库,重点在于 "你为什么选这个、它不是万能的、还有哪些补充方案"。

标准话术

"我们用的向量数据库是 Milvus,主要原因是它是开源方案里分布式做得最成熟的,支持十亿级别的向量规模,而且有完整的 Java SDK。部署上我们用 K8s operator 管理,分片和副本可以根据数据量动态调整。不过向量数据库也不是万能的——对于精确的关键词检索(比如搜索订单号、手机号),向量检索不如 Elasticsearch 的倒排索引。所以我们的架构是 向量+关键词混合检索:向量检索做语义召回,ES 做精确匹配,最后合并排序。"

3.5 LangChain4j vs. Spring AI 框架对比

趋势说明

Java 生态中整合 LLM 的主要有两个框架:LangChain4j(社区驱动,LangChain 的 Java 移植版)和 Spring AI(Spring 官方出品)。两者各有优劣,面试中对比它们可以展示你的技术视野。

对比维度LangChain4jSpring AI
背景社区项目,受 LangChain (Python) 启发Spring 官方项目
发布年份20232023 (2024 正式版)
与 Spring 集成独立库,可集成原生 Spring 整合,自动配置
模型支持OpenAI / Ollama / 通义千问 / 文心 / DeepSeekOpenAI / Ollama / 通义千问 / DeepSeek
RAG 支持丰富(多种切分/检索/重排策略)基础(正在增强中)
Agent 支持强(支持 ReAct / 多 Agent 编排)基础(Function Calling 级别)
向量存储多种(Milvus / Pinecone / Chroma / ES)多种(同左)
学习曲线中(API 较多)低(IDE 自动补全友好)
文档质量好(Community 驱动)优秀(Spring 官方文档风格)
国内模型支持较好(社区贡献)较好(官方支持)

使用场景建议

场景推荐框架理由
简单的 LLM 调用(翻译/摘要/生成)Spring AI配置简单,Spring 原生集成
RAG 知识库LangChain4j更丰富的文档处理和检索策略
复杂的 Agent 编排LangChain4j多步骤、多工具、条件分支
新项目快速上手Spring AI学习成本低,社区活跃
两者结合用后台 LangChain4j 做复杂逻辑,Spring AI 做简单交互各有优势,不冲突

面试关联

面试官问框架对比,考察的是 技术选型能力——你不是在用框架,而是在"选择"框架。

标准话术

"我们团队两个框架都在用。简单场景比如 商品描述的自动生成,用的 Spring AI,因为它的 ChatClient 写起来很简洁,一行代码就能调用 LLM,和 Spring Boot 项目天然集成。复杂场景比如 智能客服的 RAG 流程,用的 LangChain4j,因为它的 ContentRetriever 和 DocumentSplitter 更加灵活,可以自定义切分策略和检索逻辑。我的建议是:不要二选一,而是根据场景选择。Spring 官方和社区也在推动两者的整合,未来可能会像 SLF4J 和 Logback 的关系那样——Spring AI 做抽象层,LangChain4j 提供扩展实现。"


4. 数据技术演进

4.1 实时数仓(ClickHouse / Doris)的崛起

趋势说明

传统的大数据架构(Hadoop + Hive + Spark)在面对"实时查询"需求时显得力不从心。ClickHouse(列式存储,OLAP 查询快 100-1000 倍)和 Apache Doris(百度开源,兼容 MySQL 协议)正在成为实时数仓的标配。

MySQL / ClickHouse / Doris 定位对比

特性MySQLClickHouseApache Doris
定位OLTP 在线交易OLAP 实时分析OLAP 实时分析
数据模型行存列存列存
并发写入高(事务支持)极高(批量导入)高(微批导入)
复杂查询慢(大表 Join)极快快
数据一致性强(ACID)最终一致强
SQL 兼容完美一般(方言)好(兼容 MySQL)
运维成本低中中
典型场景订单/用户日志/指标/行为分析多维报表/大屏

实时数仓的典型架构

应用服务 (MySQL)
    │
    │  Canal / Flink CDC
    ▼
实时数据接入层 (Kafka)
    │
    ├──→ Flink 实时ETL ──→ ClickHouse / Doris
    │                        │
    │                        ▼
    │                    BI大屏 / 实时报表
    │
    └──→ Spark 离线ETL ──→ Hive / HDFS (历史归档)

Java 后端整合 ClickHouse

// ClickHouse JDBC —— 和 MySQL 用法一样
@Repository
public class ClickHouseRepository {

    private final JdbcTemplate clickHouseJdbc;

    // 实时 PV/UV 查询
    public List<PageStats> queryPageStats(LocalDate date) {
        String sql = """
                SELECT 
                    page_url,
                    count(DISTINCT user_id) AS uv,
                    count(*) AS pv
                FROM event_log
                WHERE toDate(event_time) = ?
                    AND event_type = 'page_view'
                GROUP BY page_url
                ORDER BY pv DESC
                LIMIT 10
                """;
        return clickHouseJdbc.query(sql, new PageStatsRowMapper(), date);
    }
}

面试关联

问题回答方向
"你们用 ClickHouse 做什么?"用户行为分析、运营报表、监控日志聚合
"为什么不用 ES 做分析?"ES 适合搜索,OLAP 聚合性能不如 ClickHouse
"实时数仓的延迟是多少?"Flink CDC 分钟级,全链路 < 5 分钟

标准话术

"我们公司用 ClickHouse 搭建了实时数仓。业务场景是这样的:MySQL 里的订单数据通过 Flink CDC 实时同步到 ClickHouse,然后业务方可以在秒级跑出多维度的销售报表——按品类、地区、时间维度的聚合查询。之前用 MySQL 跑同样的报表需要 10 多秒,ClickHouse 把查询时间降到了 100ms 以内。不过 ClickHouse 的运维要注意 MergeTree 的合并策略,如果数据量太大合并不过来,查询性能会下降。我们采用了 多层分区(按天分区 + 按小时分桶),并且定期执行 OPTIMIZE 操作来强制合并。"

4.2 Flink CDC 替代 Canal 的趋势

趋势说明

Canal(阿里巴巴开源的 MySQL binlog 订阅组件)长期以来是 MySQL 数据同步的首选方案。但 Flink CDC(基于 Flink 的变更数据捕获)正在快速替代 Canal,成为 CDC 的新标准。

Canal vs. Flink CDC 对比

对比维度CanalFlink CDC
架构独立部署的 ServerFlink Job(和 Flink 生态一体)
数据格式自定义 MessageDebezium 格式(标准 JSON)
下游主要支持 Kafka任何 Flink 支持的 sink(Kafka/ES/ClickHouse/MySQL)
数据变换弱(需要额外开发)强(Flink 流式计算直接做 ETL)
断点续传支持(ZK 记录位点)支持(Flink Checkpoint,更可靠)
全量+增量不支持全量(需额外工具)支持(Snapshot + Binlog 自动衔接)
DDL 变更部分支持自动感知 Schema 变更
运维成本低(独立组件)中(需要 Flink 集群)
// Flink CDC —— Java 代码完成同步
public class MysqlCdcToClickHouse {

    public static void main(String[] args) {
        // 1. 定义 MySQL CDC 源
        MySqlSource<String> mySqlSource = MySqlSource.<String>builder()
                .hostname("localhost")
                .port(3306)
                .databaseList("order_db")
                .tableList("order_db.orders")
                .deserializer(new JsonDebeziumDeserializationSchema())
                .build();

        // 2. 构建 Flink 流处理
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        env.enableCheckpointing(5000);
        
        env.fromSource(mySqlSource, WatermarkStrategy.noWatermarks(), "MySQL CDC")
                .map(new TransformFunction())  // 在流中直接做 ETL
                .sinkTo(ClickHouseSink.builder()  // 直接写入 ClickHouse
                        .setHost("clickhouse:8123")
                        .build()
                );

        env.execute("MySQL CDC -> ClickHouse Sync");
    }
}

面试关联

面试中聊 Flink CDC,重点在于 "它比 Canal 好在哪 + 我们在什么场景用了它"。

标准话术

"我们最近把几个核心的 MySQL 同步链路从 Canal 迁移到了 Flink CDC。主要原因是我们需要一个 全量+增量 的同步能力。Canal 只能做增量同步,初始化时需要用 DataX 先导全量数据,两边的时间戳很难对齐。Flink CDC 的 Snapshot 机制可以在启动时自动做全量快照,然后无缝切换到增量同步,不需要额外的全量工具。另外,我们在同步过程中还需要做一些数据变换——比如订单金额的单位转换、状态值的映射——用 Flink CDC 可以在 SQL 里直接完成,省掉了一个中间 ETL 服务。"

4.3 图数据库(Neo4j)的应用扩展

趋势说明

图数据库正在从"社交网络专属"走向更广泛的企业应用场景。Neo4j 是图数据库的标杆产品,在 推荐系统、风控规则引擎、知识图谱、权限管理 等领域有广泛应用。

图数据库 vs. 关系型数据库

场景MySQL(关系型)Neo4j(图数据库)
好友关系(二度人脉)自关联 Join,性能差图遍历,毫秒级
权限继承链多层 Join 或递归 CTE图路径查询
风控团伙识别极难(需要多表 Join)图算法(社区发现)
商品推荐链路复杂 SQL图游走算法
// Spring Data Neo4j —— 用对象图的方式操作图数据库
@Node("User")
public class UserNode {
    @Id
    private String userId;
    private String name;

    @Relationship("FOLLOWS")
    private Set<UserNode> follows;

    @Relationship("PURCHASED")
    private Set<ProductNode> purchased;
}

// 查询:"推荐好友购买过的商品"
@Repository
public interface RecommendationRepository extends Neo4jRepository<UserNode, String> {

    @Query("""
        MATCH (user:User {userId: $userId})
            -[:FOLLOWS]->(friend:User)
            -[:PURCHASED]->(product:Product)
        WHERE NOT (user)-[:PURCHASED]->(product)
        RETURN product, count(*) AS score
        ORDER BY score DESC
        LIMIT 10
        """)
    List<ProductRecommendation> recommendProducts(String userId);
}

面试关联

问题回答方向
"什么场景适合用图数据库?"关系复杂、多跳查询、非结构化关系网络
"Neo4j 的缺点?"分布式支持不如 MySQL,事务 TPS 相对低
"图数据库和关系型数据库能一起用吗?"可以(互补模式——MySQL 存核心交易数据,Neo4j 存关系数据)

标准话术

"我们在风控系统中用了 Neo4j 来构建 团伙关系图谱。一个典型的场景是:多个账号共用同一台设备、同一个 IP、同一个收货地址,这些账号之间就存在关联。用 MySQL 做这种多度关联查询非常痛苦——需要反复 Join 自己,SQL 写出来又长又慢。Neo4j 就适合多了,一条 Cypher 查询就能找到所有有交集的账号。不过图数据库不擅长高并发的事务场景,我们的架构是 MySQL 做主存储 + Neo4j 做关系分析——MySQL 存用户的交易流水,Neo4j 存用户之间的关系边。"

4.4 时序数据库(TDengine / InfluxDB)在 IoT 监控中的应用

趋势说明

IoT(物联网)和可观测性的发展催生了时序数据库的旺盛需求。TDengine(国产开源、涛思数据)和 InfluxDB(老牌 TSDB)是这个领域的代表。

TDengine vs. InfluxDB vs. Prometheus

对比维度TDengineInfluxDBPrometheus(TSDB 部分)
架构SQL 原生,类 MySQL自定义查询语言 FluxPromQL
性能(写入)极高(单节点百万点/秒)高高
压缩比1/10 - 1/201/5 - 1/101/3 - 1/5
集群原生支持企业版Thanos/Cortex
超级表✓ 自动建子表✗✗
Java 生态JDBC 驱动(和 MySQL 用法一致)HTTP APIHTTP API + Micrometer
// TDengine JDBC —— 和操作 MySQL 一样
@Service
public class IotMonitorService {

    private final JdbcTemplate tdJdbc;

    // 创建超级表(自动创建子表)
    public void createSuperTable() {
        tdJdbc.execute("""
                CREATE STABLE IF NOT EXISTS sensor_data (
                    ts TIMESTAMP,
                    temperature DOUBLE,
                    humidity DOUBLE
                ) TAGS (device_id VARCHAR(64), location VARCHAR(128))
                """);
    }

    // 插入数据(自动按 TAG 创建子表)
    public void insertData(String deviceId, double temperature, double humidity) {
        tdJdbc.update("""
                INSERT INTO device_? USING sensor_data TAGS (?, ?)
                VALUES (NOW, ?, ?)
                """, deviceId, deviceId, "Beijing", temperature, humidity);
    }

    // 查询某设备最近一小时的温度平均值
    public Double queryAvgTemperature(String deviceId) {
        return tdJdbc.queryForObject("""
                SELECT AVG(temperature) 
                FROM sensor_data
                WHERE device_id = ? 
                    AND ts >= NOW - 1h
                """, Double.class, deviceId);
    }
}

TDengine 的超级表(Super Table)是一个非常巧妙的设计:用 "一个超级表定义 schema" + "按设备自动建子表" 的方式,既保证了写入性能(每个子表独立文件),又避免了海量表的管理问题。

面试关联

标准话术

"我们公司在 IoT 设备监控场景用了 TDengine,主要监控几百台机器的运行状态(CPU 温度、震动频率、能耗等),每台机器每 5 秒上报一次数据。TDengine 的超级表模型很适合这个场景:不需要为每台设备手动建表,写入时自动按 device_id 创建子表,查询特定设备的数据非常快。数据压缩效果也不错,7x24 小时的数据,存储空间只有原始数据量的 1/15 左右。不过 TDengine 的生态还在发展,比如和 Grafana 集成时有些高级功能不支持,我们搭配了 Prometheus 一起用。"


5. 安全与合规

5.1 零信任架构(Zero Trust)

趋势说明

零信任(Zero Trust)的核心思想是 "永不信任,始终验证"。传统内网安全模型假设"内网是安全的",零信任架构则假定 网络永远是不可信的,无论请求来自内网还是外网,都需要进行身份验证和授权。

传统边界安全模型:             零信任架构:
┌───────────────┐        ┌──────────────────────┐
│  企业内网       │        │  身份为边界            │
│  ┌───────┐    │        │                       │
│  │ 内网应用 │    │        │  ┌──────┐  ┌──────┐  │
│  └───────┘    │        │  │ 用户  │  │ 设备  │  │
│       │ 默认信任  │        │  └──┬───┘  └──┬───┘  │
│       ▼        │        │     └──┬──┘        │
│  ┌───────┐    │        │        ▼            │
│  │ 数据库  │    │        │  ┌──────────────┐ │
│  └───────┘    │        │  │ 身份认证网关    │ │
│               │        │  │ (验证身份+设备+  │ │
│  ✗ 一旦进入内网  │        │  │  权限+上下文)   │ │
│  就可以横向移动  │        │  └──────┬───────┘ │
└───────────────┘        │        │            │
                          │        ▼            │
                          │  ┌────────────────┐ │
                          │  │  应用/数据      │ │
                          │  │  (最小权限)     │ │
                          │  └────────────────┘ │
                          └──────────────────────┘

零信任在后端的实践要点

实践维度实现方式后端技术
身份认证多因素认证(MFA)OAuth2 + OTP
设备验证设备指纹 + 证书mTLS
最小权限细粒度 RBAC/ABACSpring Security + 权限模型
网络隔离微隔离(Micro-segmentation)K8s NetworkPolicy + Istio
持续验证每个请求都要验证网关层 + 服务间 mTLS
审计日志全量记录Filebeat + ELK

面试关联

零信任更多是安全架构层面的概念,面试中重点是体现 "有安全意识",而不是要求深度技术细节。

标准话术

"我理解零信任的核心理念是 身份即边界——不再相信内网/外网的划分,每一次请求都有经过认证和授权。我们在公司实践中,服务间调用用了 mTLS 双向认证(Istio 自动注入),每个请求都经过身份验证。API 层面做了 细粒度的权限控制,不只检查用户有没有登录,还要检查用户是否有操作这个资源的权限。数据库访问也统一走中间件层,不允许服务直连数据库。这样做的一个好处是:即使内网被攻破了一台机器,攻击者也无法横向访问其他服务。"

5.2 软件供应链安全(SBOM / 依赖扫描)

趋势说明

软件供应链安全在 2024 年 Log4j 漏洞事件后成为行业焦点。SBOM(Software Bill of Materials,软件物料清单)成为软件交付的 新标准要求。

什么是 SBOM

你的应用:
├── Spring Boot 3.2.0
│   ├── Spring Core 6.1.0
│   │   ├── spring-jcl 6.1.0
│   │   └── ...
│   ├── Spring Web 6.1.0
│   └── ...
├── MyBatis-Plus 3.5.5
│   ├── MyBatis 3.5.15
│   └── ...
├── RocketMQ Client 5.1.0
├── MySQL Connector 8.0.33
└── ...

SBOM = 你用了什么 + 什么版本 + 有没有漏洞 + 许可证是什么

Java 项目中的依赖扫描实践

<!-- Maven 插件:生成 SBOM + 依赖扫描 -->
<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <version>2.7.9</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>makeBom</goal>  <!-- 生成 SBOM (cyclonedx格式) -->
            </goals>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.0.9</version>
    <configuration>
        <failBuildOnCVSS>7</failBuildOnCVSS>  <!-- CVSS >= 7 的漏洞会导致构建失败 -->
        <formats>
            <format>HTML</format>
            <format>JSON</format>
        </formats>
    </configuration>
</plugin>
# 生成 SBOM
mvn cyclonedx:makeBom
# 输出: target/bom.json

# 依赖漏洞扫描
mvn dependency-check:check
# 输出: target/dependency-check-report.html

面试关联

问题回答方向
"你们怎么避免 Log4j 这类漏洞?"依赖扫描 + 自动升级 + 定期审计
"SBOM 是什么?"软件物料清单——用机器可读的格式列出所有依赖及版本
"供应链安全怎么落地?"CI/CD 中集成 OWASP Dependency-Check

标准话术

"Log4j 漏洞事件之后,我们公司对供应链安全做了系统性的改进。第一是在 CI/CD 流水线 中集成了 OWASP Dependency-Check 插件,每次构建都会扫描所有依赖的已知漏洞,CVSS 评分 7 以上的漏洞会直接阻断构建。第二是建立了 SBOM(软件物料清单) 的生成和归档机制,每次发布都会生成一份 CycloneDX 格式的 SBOM,存到公司内部的物料清单管理平台。这样一旦有新的 CVE 爆出来,可以快速定位哪些服务、什么版本受影响。第三是我们对 Maven 仓库做了 私有仓库代理,所有外部依赖经过审核后才能被项目使用,避免开发者引入不安全或不合规的依赖。"

5.3 API 安全网关的演进

趋势说明

API 安全网关正在从"简单的 API 管理"演进为 企业级 API 安全防护的统一入口。Kong、APISIX、Spring Cloud Gateway 等网关都在增强安全能力。

API 安全网关的核心能力

┌───────────────── API 安全网关 ──────────────────┐
│                                                    │
│  ① 认证 (Authentication)                         │
│  ┌─────────────────────────────────────────────┐ │
│  │ JWT / OAuth2 / OIDC / SAML / API Key       │ │
│  │ 多认证方式并存                               │ │
│  └─────────────────────────────────────────────┘ │
│                                                    │
│  ② 授权 (Authorization)                          │
│  ┌─────────────────────────────────────────────┐ │
│  │ RBAC / ABAC / 细粒度权限                     │ │
│  └─────────────────────────────────────────────┘ │
│                                                    │
│  ③ 安全防护 (Security)                           │
│  ┌─────────────────────────────────────────────┐ │
│  │ 限流 / 防重放 / SQL注入检测 / XSS过滤       │ │
│  │ 敏感数据脱敏 / 请求合法性校验                │ │
│  └─────────────────────────────────────────────┘ │
│                                                    │
│  ④ 审计 (Audit)                                  │
│  ┌─────────────────────────────────────────────┐ │
│  │ 全量请求日志 / 异常检测 / 合规审计           │ │
│  └─────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────┘

Spring Cloud Gateway 的安全增强

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/api/order/**
          filters:
            # JWT 校验过滤器
            - name: JwtAuthentication
              args:
                issuer: https://auth.company.com
            # 限流过滤器
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 100
                redis-rate-limiter.burstCapacity: 200
            # 请求日志(审计用)
            - name: AuditLogging

面试关联

标准话术

"我们使用 Spring Cloud Gateway 作为 API 网关,在上面集成了几层安全能力。最外面是 认证层——统一校验 JWT Token,支持多端(Web、小程序、第三方开放平台)不同的认证方式。接着是 限流和防滥用——用 Sentinel 做精细化限流,按 API、用户、IP 多个维度配置。再往里是 安全过滤——对入参做 SQL 注入检测和 XSS 过滤,敏感字段(手机号、身份证)在网关层脱敏后再传给下游。最后是 审计日志——所有请求的完整链路信息和请求参数都记录到 ELK,用于安全审计和事后追溯。"

5.4 数据安全法 / 个保法下的技术合规要求

趋势说明

《数据安全法》和《个人信息保护法》(简称"个保法")自 2021 年实施以来,对企业的技术要求产生了深远影响。2025-2026 年,监管力度进一步加严,合规从"可选择"变成了"必须做"。

后端开发必须关注的合规技术要点

合规要求技术实现涉及的技术栈
数据分类分级建立数据分级标注体系元数据管理
数据脱敏敏感字段在存储和展示时脱敏脱敏工具、MyBatis 拦截器
数据加密存储加密 + 传输加密AES-256、mTLS、TLS 1.3
数据最小化只采集业务必要的数据代码审查、API 设计规范
数据生命周期自动过期清理机制定时任务、TTL 索引
数据跨境数据本地化存储地域限制、多云部署
用户权利响应提供查询/修改/删除接口API 设计、用户中心
数据泄露报告自动检测 + 告警安全监控、SIEM
// 数据脱敏的 AOP 实现
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DataMask {
    MaskType type();
}

@Aspect
@Component
public class DataMaskAspect {

    @Around("@annotation(dataMask)")
    public Object mask(ProceedingJoinPoint pjp, DataMask dataMask) throws Throwable {
        Object result = pjp.proceed();
        if (result instanceof String) {
            return maskString((String) result, dataMask.type());
        }
        // 反射处理对象中的敏感字段
        return maskObject(result, dataMask.type());
    }

    private String maskString(String value, MaskType type) {
        return switch (type) {
            case PHONE -> value.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2");
            case ID_CARD -> value.replaceAll("(\\d{4})\\d{10}(\\d{4})", "$1**********$2");
            case NAME -> value.replaceAll("(?<=.).", "*");
            default -> value;
        };
    }
}

// 使用
@RestController
public class UserController {

    @GetMapping("/user/{id}")
    @DataMask(type = MaskType.PHONE)  // 返回的手机号自动脱敏
    public UserVO getUser(@PathVariable Long id) {
        return userService.getUser(id);
    }
}

面试关联

面试中聊数据合规,关键是体现 "我知道有这些要求,并且在我的代码里做了对应实现",而不是背诵法律条文。

标准话术

"数据安全法对我们后端开发最直接的影响是 敏感数据的处理方式。我们在公司制定了数据分级标准:L1 是公开数据、L2 是内部数据、L3 是敏感数据(如手机号、身份证号)、L4 是绝密数据(如支付密钥)。L3 以上的数据在接口返回时自动脱敏,通过 AOP 注解实现,不需要业务开发手动处理。数据库存储方面,L4 数据用了 AES-256 加密,密钥由独立的密钥管理服务(KMS)管理,应用只持有临时的解密令牌。另外我们还在网关层做了 用户数据导出审计——任何批量导出用户数据的操作都需要审批,并且会记录完整的操作日志。"


6. 低代码/无代码对后端的影响

6.1 低代码平台的定位:不是替代,是提效

趋势说明

低代码/无代码平台在 2025-2026 年进入了 务实的增长期。不同于早期的"取代程序员"的激进口号,现在的共识是:低代码是提效工具,不是替代方案。

低代码平台的能力边界

┌────────────────────────────────────────────────┐
│              企业内部应用场景                     │
│                                                  │
│  ┌─────────────┐  ┌─────────────┐               │
│  │  表单/审批   │  │  报表/大屏  │  ← 低代码擅长  │
│  │  内部OA      │  │  数据看板   │               │
│  └─────────────┘  └─────────────┘               │
│                                                  │
│  ┌─────────────┐  ┌─────────────┐               │
│  │  API 编排   │  │  简单 CRUD  │  ← 低代码部分覆盖│
│  │  (简单逻辑)  │  │  后台管理   │               │
│  └─────────────┘  └─────────────┘               │
│                                                  │
│  ┌─────────────┐  ┌─────────────┐               │
│  │  核心业务   │  │  高并发系统  │  ← 低代码不擅长 │
│  │  复杂逻辑   │  │  分布式事务  │               │
│  └─────────────┘  └─────────────┘               │
└────────────────────────────────────────────────┘

低代码平台 vs. 传统后端开发

对比维度低代码平台传统后端开发
开发速度快(拖拽 + 配置)慢(编码 + 测试)
灵活性低(受平台能力限制)高(任何逻辑都可实现)
性能中等高(可深度优化)
可维护性依赖平台厂商高(代码可控)
复杂业务不擅长擅长
高并发一般擅长
部署方式云托管为主灵活(任何环境)

面试关联

问题回答方向
"低代码会取代后端开发吗?"不会——低代码解决的是"有无"问题,后端解决的是"好坏"问题
"你们公司有用低代码平台吗?"有,但仅限内部工具和管理后台
"低代码和你们开发的系统怎么集成?"低代码平台通过 API 调用后端服务

标准话术

"我对低代码平台的理解是:它解决的是'快速实现'的问题,而不是'高质量实现'的问题。我们公司内部在用低代码平台搭建运营后台和审批流程,之前这些场景需要前端和后端各投入一个人,现在运营同学自己拖拽就能完成,确实提升了效率。但真正 高并发、高一致性、高复杂度 的核心业务——比如订单系统、支付系统、库存管理系统——还是必须用传统后端开发。低代码平台在我们的架构里是一个 SaaS 层,它调用后端微服务暴露的 OpenAPI 来获取数据和执行业务。作为后端开发,我们的职责是提供稳定、高性能、安全的 API 给上层使用,无论上层是用低代码平台还是自研前端。"

6.2 后端开发如何与低代码平台共存

趋势说明

2025-2026 年的现实是:低代码平台已经存在,并且会继续增长。后端开发需要理解如何与低代码平台互补共存,而不是对立。

后端开发的新机会

方向具体工作价值
API 设计设计清晰、稳定、高性能的 API低代码平台通过 API 对接
领域服务封装核心业务逻辑为领域服务低代码平台编排服务组件
数据底座数据建模、数据治理、数据安全低代码平台使用数据服务
平台能力作为"平台工程"的一部分为低代码平台提供基础能力
复杂问题处理低代码平台解决不了的难题高并发、分布式事务、实时计算
// 后端提供的"能力原子"——供低代码平台编排
@RestController
@RequestMapping("/api/atoms")
public class BusinessAtomController {

    // 原子能力:创建订单
    @PostMapping("/order/create")
    public Result<OrderVO> createOrder(@RequestBody CreateOrderRequest request) {
        // 复杂的业务逻辑:库存校验、价格计算、风控检查
        return Result.success(orderService.create(request));
    }

    // 原子能力:查询物流
    @GetMapping("/logistics/track")
    public Result<List<TrackVO>> trackLogistics(@RequestParam String orderId) {
        // 对接多家物流公司的统一查询
        return Result.success(logisticsService.track(orderId));
    }

    // 原子能力:退款计算
    @PostMapping("/refund/calculate")
    public Result<RefundVO> calculateRefund(@RequestBody RefundRequest request) {
        // 复杂的退款规则:优惠券分摊、满减还原、积分返还
        return Result.success(refundService.calculate(request));
    }
}

面试关联

标准话术

"我认为低代码和后端开发是 共生关系。后端开发的核心价值正在从'写 CRUD'转向'提供能力原子'。我们用低代码搭建内部工具,这些工具调用的正是后端微服务暴露的 API。低代码平台擅长的是 界面编排 和 简单逻辑串联,而底层的数据一致性、高性能、安全性、复杂业务规则,仍然是后端开发的领地。实际上,低代码平台的出现让我们后端开发可以 聚焦在更有价值的领域——设计更好的 API、优化数据模型、提升系统性能,而不是疲于应对各种内部管理后台的重复开发需求。"


7. 面试中被问"技术趋势"的高分回答框架

7.1 不要罗列名词,要展示深度

趋势说明类问题,面试官真正考察的

面试官的心理活动对应的考察点
"他是不是在背新闻标题?"是否只是记住名词,没有实际了解
"他对这个趋势有自己的理解吗?"是否有独立思考能力
"这个趋势和他做过的项目有关吗?"是否能把趋势联系到实际工作
"他说的这个趋势是真的趋势还是概念炒作?"是否有判断力,能区分"趋势"和"泡沫"
"他说的和我们的技术方向一致吗?"是否符合公司当前的技术演进方向

常见误区

✗ "我最近关注虚拟线程、Spring AI、K8s、Serverless、RAG、eBPF、Dapr..."
   (面试官反应: 你在背单词吗?哪个是深入了解过的?)

✗ "虚拟线程很厉害,性能提升很大..."
   (面试官反应: 说说怎么个厉害法?什么场景下厉害?有什么坑?)

✗ "Spring AI 是 Spring 官方出的 AI 框架..."
   (面试官反应: 然后呢?它解决了什么问题?和你有什么关系?)

✓ "我最关注的是虚拟线程,因为我们团队今年把 JDK 从 11 升到了 21..."
   (面试官反应: 好,有实际经验,可以追问细节)

核心原则

技术趋势面试回答 = 选 2-3 个深入了解的话题 + 讲清楚原理 + 关联到自己的项目/经验 + 展示自己的判断

7.2 标准回答模板

PREP 框架(Point / Reason / Example / Point)

第一步:Point(选一个趋势,给出你的观点)
  "最近我比较关注的是 [虚拟线程],我认为它是 Java 近几年最重要的性能改进..."

第二步:Reason(解释为什么这么认为,讲原理)
  "因为它的核心思想是 M:N 调度——把 Java 线程和 OS 线程解耦..."
  "传统的线程池模型下,每个请求占用一个 OS 线程,OS 线程数是有限的..."
  "虚拟线程让同一个 OS 线程可以运行成千上万个虚拟线程,I/O 时自动 yield..."

第三步:Example(用一个实际的例子或项目关联)
  "我们团队在升级到 JDK 21 后,把 Tomcat 的线程模型切换到了虚拟线程..."
  "我们做了一个压测对比,同样配置下单机 QPS 从 2000 提升到了 8000..."
  "不过也遇到了问题,有个服务用了 synchronized,导致虚拟线程 pinned..."

第四步:Point(回归核心观点,收束)
  "所以我的判断是,虚拟线程不是银弹,但在 I/O 密集型场景下..."
  "未来两年,Java 21+ 的普及会让虚拟线程成为 Java 后端的标配..."

回答时长控制

步骤时间内容
P(观点)10秒一句话表明你关注什么、你的态度
R(原理)30秒讲清楚这个趋势的核心技术原理
E(例子)60秒关联项目经验或实际观察
P(总结)20秒回归观点,给判断

总计:大约 2 分钟

7.3 完整示例回答

面试官问:"你对最近的技术趋势有什么了解?"

"我最近一段时间重点关注的趋势是 虚拟线程(Virtual Threads),我觉得它是这几年来 Java 生态中最重要的性能改进,没有之一。

(切到 R — 原理) 虚拟线程的核心是 Project Loom 引入的 M:N 调度模型。简单来说,就是在 Java 虚拟机和 OS 线程之间加了一层调度层。以前我们说的 'Java 线程' 直接对应一个 OS 线程,数量受限于 OS 资源,一个 OS 线程大约占 1MB 栈空间,所以一台机器跑几千个线程就到了极限了。虚拟线程则是一个 Java 对象,只占几千字节,同一时间可以创建上百万个。当虚拟线程遇到 I/O(比如数据库查询、RPC 调用),它会自动从 Carrier Thread 上 yield 下来,Carrier Thread 立即去执行另一个虚拟线程,完全不需要阻塞。

(切到 E — 项目关联) 这个变化对我们团队的影响很大。我们的业务主要是 I/O 密集型的(大量数据库操作 + 外部 API 调用),去年在升级到 Java 21 后,我们在 QA 环境做了一个对比压测。在 Tomcat 用虚拟线程 替代传统线程池后,同样的 4C8G 机器,TPS 从原来的 2500+ 提升到了 8000+,而且响应时间更稳定了,没有因为线程切换导致的延迟毛刺。不过我们也踩了坑:有一个模块大量使用了 synchronized 关键字做同步,这会导致虚拟线程 pinned 住 Carrier Thread,反而拉低了性能。解决方案是把 synchronized 替换成 ReentrantLock。另外之前依赖 ThreadLocal 做上下文传递的地方,在虚拟线程下要特别注意用完 remove,否则内存泄漏会很严重。

(切到 P — 总结观点) 所以我对虚拟线程的判断是:它会彻底改变 Java 后端的并发编程方式。未来两年,响应式编程框架(WebFlux、RxJava)的需求会显著下降,大家会回归到更简单的同步编程模型。但这不意味着虚拟线程能解决所有问题——CPU 密集型计算还是要用传统的线程池隔离。我们团队也在计划在更多的服务中推行虚拟线程,同时也在关注 JDK 25 中的 Structured Concurrency 和 Scoped Values 这两个配套特性。"

7.4 三个常见趋势的快速回答模板

模板 A:AI 与后端融合

"我最近比较关注 AI 在 Java 后端的工程化落地。我认为 2025 到 2026 年,AI 不是独立的系统,而是后端基础设施的一个组成部分。

比如 RAG 架构 让后端服务可以直接给 LLM 提供业务上下文。我们在客服系统里做了这个——用户提问后,后先从 Milvus 检索相关文档,再和问题一起发给 LLM,回答准确率提升了很多。

工具层面,Spring AI 和 LangChain4j 两个框架让我可以在 Java 项目里用几行代码就完成 LLM 的调用,不需要 Python 中转。

我的判断是:以后后端开发不只是写 CRUD,还要会 设计 AI 工作流、写 Prompt Template、评估 AI 输出质量。这个趋势和我们后端开发者的能力是匹配的——我们擅长工程化、流程编排和质量保障,只是新的对象是 LLM 而不是数据库。"

模板 B:云原生深化

"我关注的是 云原生从 '容器化' 深化到 '精细化治理'。以前大家讲云原生就是 Docker + K8s,现在 K8s 已经成了标配,大家开始关注更深层的运营效率。

比如 FinOps(云财务运营)——我们公司去年引入了成本分析,发现很多服务申请了 4C8G 的资源配置,实际 CPU 使用不到 10%。通过 Prometheus 历史数据分析和 VPA(Vertical Pod Autoscaler)推荐,我们把很多服务的资源配置降到了合适的规格,一年省了几十万云费用。另外 GitOps 也在我们团队落地了——用 ArgoCD 做声明式部署,配置即代码,出了问题可以一键回滚到上一个 Git commit。

我的判断是:未来后端开发对云原生能力的要求会从'会用 K8s 部署'升级到'能优化资源成本、能设计多活架构'。"

模板 C:Java 新版本与生态进化

"我特别关注的是 Java 版本演进的节奏。Java 21 是我认为自 Java 8 以来最重要的 LTS,它引入了虚拟线程、Record Pattern、Pattern Matching 等一批现代语言的特性。

我关注的不只是语法糖,而是它对设计模式的影响。比如 Sealed Class + Pattern Matching 让传统的策略模式可以用更简洁、更安全的方式表达,编译器可以检查所有分支是否覆盖完整,减少了 if-else 的出错可能。我们在业务代码里用 Record 替代了大部分的 Lombok @Data,代码干净了很多。

版本演进方面,考虑到安全补丁和性能改进,我们团队已经确定 Java 21 是新的基线版本,新项目全部基于此版本。遗留项目也在按计划分批升级。

我的判断是:Java 的版本演化已经证明 '快节奏发布' 是有效的,短期内不会有另一个 Java 8 那样的 '版本断层'。对于开发者来说,每 6 个月关注一次新特性是一个成本很低但收益很高的习惯。"


8. 2025-2026 年 Java 后端技术栈展望

8.1 未来 1-2 年哪些技术会火

基于当前趋势的推演

技术方向预测热度判断依据
Spring AI / LangChain4jAI 进入企业的刚需 + Java 生态缺少标准 AI 整合方案
Virtual Threads 普及Java 21 成为主流 LTS,虚拟线程生态成熟,性能红利明显
RAG 架构标准化企业 AI 落地首选架构,各种脚手架和 SaaS 服务成熟
GraalVM Native ImageServerless 场景驱动 + 启动性能需求 + 构建工具优化
K8s Gateway API替代 Ingress,提供更强大的流量治理能力
Flink CDC实时数据同步需求旺盛,替代 Canal + DataX 组合
FinOps(云成本优化)企业降本增效的刚需,K8s 成本可视化工具成熟
OpenTelemetry可观测性标准统一,Prometheus/Grafana/SkyWalking 都在集成
eBPF 可观测性零侵入监控,底层技术成熟,但中大型企业才能发挥价值
Structured Concurrency虚拟线程的配套,结构化并发的编程范式
# 2026 年典型 Java 后端项目的技术栈(预测)
project:
  language: Java 25 (LTS) + Virtual Threads
  framework: Spring Boot 4.x + Spring Framework 7.x
  database: MySQL 9.0 + Redis 8.0 + PostgreSQL 17
  AI:
    framework: Spring AI 1.x + LangChain4j
    models: DeepSeek V4 + GPT-5 (多模型策略)
    vector: Milvus 3.x (自建) / Pinecone (云)
    agent: MCP Protocol (标准)
  streaming: Flink CDC + Kafka 4.0 + ClickHouse 25.x
  cloud:
    orchestration: K8s 1.32+ + Istio 1.24
    serverless: Knative + GraalVM Native Image
    cost: K8s VPA + KubeCost (FinOps)
  observability: OpenTelemetry + Grafana 12 + Pyroscope (连续分析)
  security: mTLS + OIDC + SBOM (CycloneDX) + Dependency-Check

8.2 哪些技术在衰落(需要避坑)

正在或即将被淘汰的技术

技术衰落原因替代方案
Java 8已停止安全更新,新框架不再支持Java 21+(迁移成本高,但必须做)
Spring Cloud Netflix组件进入维护期,不再迭代Spring Cloud Alibaba / Spring Cloud Official
Hystrix停止维护,Sentinel 功能更强Sentinel / Resilience4j
Zuul 1.x阻塞式网关,性能差Spring Cloud Gateway(非阻塞)
Swagger / SpringFox生态停滞,OpenAPI 规范更新不及时SpringDoc OpenAPI / Knife4j
Log4j 1.x安全漏洞多,已 EOLLog4j 2.x / Logback
传统单体架构不适合现代 DevOps 和云原生微服务(但有节制,不是所有场景都适合微服务)
手动运维效率低,易出错,不可复现Infrastructure as Code(Terraform / Ansible)
Spring Security OAuth2已被 Spring Security 5+ 内置Spring Security 6+ OAuth2 模块
WebFlux(部分场景)虚拟线程解决了 I/O 密集型的痛点虚拟线程 + Spring MVC(同步编程更简单)

关于 WebFlux 的特别说明:WebFlux 在虚拟线程之前是处理高并发 I/O 的最佳方案。但虚拟线程的成熟让 Spring MVC + 同步编程在大多数场景下成为了更好的选择。WebFlux 不会消失,它仍然在 连接数极高且每个连接计算量很少 的场景下有优势(比如网关、消息代理),但主流业务场景会回归 Spring MVC。

避坑建议

避坑原则:
1. 不学已经宣布 EOL(停止维护)的技术
2. 不学只有大厂在用、中小公司几乎不用的技术
3. 不学文档不全、社区冷清的技术
4. 谨慎选择"刚发布就火了"的技术(可能是过度炒作)
5. 优先学"能和自己当前项目结合"的技术(学以致用才不会忘)

8.3 个人学习建议

按角色和阶段推荐的学习路径

方向 A:应届生 / 1-3 年经验

目标:打好基础,建立技术视野

优先级 P0(必须掌握):
├── Java 21+ 新特性:虚拟线程、Record、Pattern Matching
├── Spring Boot 3.x 原理:自动配置、AOT、可观测性
├── MySQL + Redis 深度:这永远是面试最高频的知识点
└── AI 基础:至少会用 Spring AI 调一次 LLM

优先级 P1(建议掌握):
├── Docker + K8s 基础:能写 Dockerfile,能在 K8s 上部署服务
├── 一个 MQ 产品:RocketMQ 或 Kafka,理解消息模型
└── 一个 AI 方向:RAG 或 Agent,能做一个 demo

优先级 P2(加分项):
├── OpenTelemetry 可观测性
├── CI/CD 流水线搭建
└── 参与开源项目或写技术博客

方向 B:3-5 年经验(技术骨干)

目标:从"会用"到"理解原理",建立技术判断力

优先级 P0(必须掌握):
├── Java 源码层面:虚拟线程调度、JVM 调优
├── 分布式系统设计:CAP 理论、一致性协议、分布式事务
├── Spring Cloud 全套:Nacos/Sentinel/Gateway/Seata 源码级理解
└── 一个 AI 框架:LangChain4j 或 Spring AI,深入一个

优先级 P1(建议掌握):
├── K8s 进阶:Operator 开发、Helm Chart 编写
├── 一个实时数仓方案:Flink CDC + ClickHouse
├── 技术选型方法论:能说清楚"为什么选 A 而不是 B"
└── 系统性能优化:从 JVM 到 SQL 到架构的全链路优化

优先级 P2(加分项):
├── Service Mesh(Istio)概念理解
├── Dapr 多运行时架构
├── 安全合规:SBOM、零信任
└── 指导初中级开发、做技术分享

方向 C:5-10 年经验(架构师方向)

目标:建立全局视野,能主导技术演进

优先级 P0(必须掌握):
├── 架构设计能力:DDD、事件驱动、CQRS、多活架构
├── 云原生架构:Serverless + FinOps + 成本治理
├── AI 原生应用架构:RAG + Agent + MCP + 模型评估
└── 技术战略:能规划团队未来 1-2 年的技术演进路线

优先级 P1(建议掌握):
├── 组织级能力:技术债治理、工程效能提升、团队技术氛围建设
├── 跨领域知识:了解前端、运维、数据、业务
├── 技术影响力:内部分享、技术决策、对外技术布道
└── 商业思维:技术投入产出比、技术驱动业务

优先级 P2(加分项):
├── 开源社区贡献
├── 发明专利或论文
├── 行业影响力(知名技术大会分享)
└── 英语技术资料阅读能力(一手信息源)

持续学习的习惯建议

信息源(建议至少订阅 3 个):
├── InfoQ / 架构头条 —— 国内技术趋势
├── The Pragmatic Engineer —— 国际化视野
├── B站/YouTube 技术 UP 主 —— 碎片化学习
├── Spring 官方 Blog —— 生态第一手资讯
├── GitHub Trending —— 关注 Java / Go / 云原生
└── 公司内部技术分享 —— 离你最近的最佳实践

实践原则:
├── 学一个技术,就做一个 demo(不 demo 等于没学)
├── 每个技术问自己三个问题:
│   1. 它解决了什么问题?
│   2. 它和竞品比有什么优劣势?
│   3. 它在我的项目里能用吗?怎么用?
└── 每季度选择 1 个新技术深度研究(不是走马观花看文档)

✗ 避坑原则:
├── 不追刚发布 3 个月以内的"热门"技术(等冷静期)
├── 不学已经明确淘汰的技术(节省时间成本)
├── 不把"听说过"当作"了解"(面试会露馅)
└── 不为了学而学,一定要有应用场景

核心要点:技术趋势面试回答的最高境界不是"你说的都对",而是"你说得对,而且这和你做过的项目有关系"。选 2-3 个趋势深入了解,每个都能讲清 原理 → 实际应用 → 个人判断 三个层次,这比罗列 10 个名词有效 10 倍。技术视野不是一天建成的,但面试中的"趋势类问题"是完全可以通过 提前准备 + 深度思考 来制胜的。