这两年面试Java岗位特别是奔着互联网大厂去的明显能感觉到风向变了。以前背熟JVM内存模型、HashMap源码、Spring Bean生命周期基本就能过关现在面试官开口就是“你们服务怎么拆的”“分布式事务怎么做的”“有没有用AI提效”甚至直接让你现场设计一个接入大模型的接口。Spring Boot、微服务、AI这三块已经成了标配考点但大部分人准备的还是老一套八股文撞上真实场景题就容易卡壳。这篇文章我不讲虚的就把我最近复盘大厂Java面试时整理的东西全部分享出来从Spring Boot自动装配到底层原理到微服务拆分、注册中心、分布式事务的真实问法再到Java后端怎么跟大模型结合最后附上我踩过的坑和现场应对技巧。不管你是准备校招还是跳槽按这条线去准备面试时起码不会心里没底。1. 面试前的技术地图别再把八股文当全部1.1 大厂Java面试到底在考什么先看一个现象现在大厂Java面试的题目结构大约是三块拼起来的。第一块是Java基础与并发占比大概三成考察你对语言本身的掌握深度第二块是框架与架构Spring Boot、微服务、分布式都是重点占比四到五成第三块是AI与工程化这两年比重快速上升可能占到两成左右而且还在涨。很多人准备面试还是老思路把排序算法、HashMap源码、JVM调优参数背得滚瓜烂熟但一聊到项目就露馅。我见过不少候选人问“你们订单服务怎么拆的”答不上来问“MyBatis的Mapper为什么能直接注入接口”也说不清反而纠结在冒泡排序的边界条件上。不是说基础不重要而是面试官默认你基础过关他们更想确认的是你有没有架构视野和解决实际问题的能力。这里有一个很关键的认知大厂面试本质上是在筛选“来了就能干活、还能带人干活”的人。面试官问一个技术点背后往往藏着他对你项目经验、故障处理能力、设计思路的试探。所以准备面试不能只背结论要把每个技术点的“为什么”想清楚并且能跟真实业务场景挂上钩。1.2 怎么规划复习路线我建议把复习分成三条线并行推进而不是按顺序啃完一本大部头。第一条线是核心基础重点复习JVM内存结构、垃圾回收、并发工具、集合源码。这一块不用贪多把高频问题吃透就行。比如ConcurrentHashMap别只背“分段锁/CAS synchronized”要能说清楚JDK 8里为什么放弃分段锁、扩容时怎么保证线程安全、size()方法怎么统计。再比如线程池七大参数的含义、拒绝策略的适用场景、为什么阿里规约里不让用Executors创建线程池这三个层次递进面试官就会觉得你是真理解。第二条线是框架与架构Spring Boot自动装配、Spring Cloud组件选型、分布式事务方案、消息队列的应用场景。这一条线是重头戏后面几个章节我会展开讲。第三条线是AI与工程化包括大模型API怎么接入Java项目、向量数据库怎么用、RAG怎么落地、Agent开发的基本套路。这块内容比较新没有太多现成的八股文可以背反而是展示你学习能力和技术敏感度的好机会。这三条线建议用一周左右过完第一遍重点是建立知识框架。第二遍再针对薄弱点深入做一些笔记和总结。我自己的做法是用一个Markdown文档记录每个考点的“一句话结论关键源码真实案例”考前只看这个文档效率比翻书高得多。2. Spring Boot高频考点从自动装配到生产配置2.1 自动装配原理面试必问的“为什么”Spring Boot最核心的机制就是自动装配这也是面试官几乎必问的一题。很多人的回答停留在“用EnableAutoConfiguration注解开启通过SPI加载META-INF/spring.factories里的配置类”这个答案能拿及格分但拿不到高分。深入一点说Spring Boot自动装配的本质是很多个Configuration类通过条件注解按需生效。以一个典型的starter为例它会在spring.factoriesSpring Boot 3.x里是META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里声明自动配置类。应用启动时AutoConfigurationImportSelector会把所有候选配置类读出来然后经过ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty等条件判断只有满足条件才会真正生效。我面试时一般会追问一句为什么需要ConditionalOnMissingBean这个问题能看出候选人有没有真正调过Starter的源码。答案其实很朴素——让使用者能覆盖默认配置。比如你引入Redis的Starter默认帮你配好RedisTemplate但如果我自己定义了一个RedisTemplate Bean自动配置就应该让位否则就会出现Bean冲突或者行为不符合预期。还有个面试官爱问的变体自己写一个Starter需要哪几步这个问题掌握三个要素就能答清楚定义自动配置类并用条件注解控制生效时机、在META-INF里声明配置类路径、提供spring-configuration-metadata.json让IDE能提示配置项。如果项目中实际用过自定义Starter比如封装了公司内部的短信发送或日志埋点组件一定要把这个经历讲出来这是比背源码更亮眼的加分项。2.2 Spring Boot MyBatis整合的细节与坑Spring Boot与MyBatis的整合是绝大多数Java后端项目的标配面试题也常从这里出。最经典的一题Mapper接口没有实现类Spring为什么能直接注入答案的关键在MapperScannerRegistrar。它实现了ImportBeanDefinitionRegistrar启动时扫描指定包路径下所有接口把每个Mapper接口注册成MapperFactoryBean而MapperFactoryBean通过SqlSessionTemplate拿到SqlSession用JDK动态代理生成接口的代理对象。代理对象执行方法时会通过MapperMethod解析方法签名对应的SQL语句并执行。这个原理面试官一般会追问两个变体一是如果两个Mapper接口定义了相同的方法签名会怎样本质上SQL的id是namespace加方法名联合定位的所以不会冲突二是MyBatis的一级缓存和二级缓存一级缓存是SqlSession级别的默认开启二级缓存是namespace级别的需要手动配置而且跨namespace操作脏数据的问题在分布式环境里很容易踩到。再来说说配置层面的细节。热词里有人提到“mybatisplus根据Java实体类生成创建表的SQL语句”这个场景在生产环境很常见。MyBatis-Plus提供了多种建表方案比较稳妥的是用db-async或table-init这类工具在应用启动时自动同步表结构。但我要提醒一句自动建表工具只适合开发环境和快速原型阶段生产环境的表结构变更必须走专门的脚本管理和审核流程否则遇到大批量字段变更时自动同步很容易把线上的表搞坏。2.3 端口配置、启动失败与JVM参数调优Spring Boot修改端口号是个看似简单但面试里可能变着法子考的点。最直接的方式是在application.yml里写server.port8081命令行启动时用--server.port8082覆盖还可以通过环境变量SERVER_PORT来指定。这里有个细节很多人不知道配置的优先级是命令行参数 Java系统属性 环境变量 application.yml application.properties这个顺序在排查“为什么改了配置文件不生效”时特别有用。启动失败是面试里的高频场景题。比如“如果Spring Boot应用启动时报端口被占用你怎么排查”常规答案是先netstat -ano找到占用进程再决定kill还是换端口。但更好的回答是说出业务层面的思路如果是线上环境不能随便kill要看是不是同一个应用部署了两份或者是监控探活把服务拉起来了多次还要考虑优雅停机的问题。再比如说Java进程堆内存溢出也就是java.lang.OutOfMemoryError不少候选人的第一反应就是调大-Xmx。真要调大也没错但要分清是堆内存溢出还是元空间溢出还是线程创建过多导致的无法分配内存。解决这类问题不能只靠拍脑袋调参数正确姿势是先把堆dump下来用MAT或JProfiler分析是对象堆积还是内存泄漏定位到具体的业务代码后再做优化。我在实际操作中还发现一个高频坑IDE里启动多个服务时很容易因为环境变量没配好导致启动失败。比如你是用IntelliJ IDEA同时跑微服务的多个模块不同模块需要不同的Nacos地址、不同的数据库配置如果共用一套Run Configuration就会互相踩。我建议每个模块单独建Run Configuration把VM options和Environment variables分开模板化保存这样换机器、换环境也方便。3. 微服务架构面试实战拆分、治理与分布式难题3.1 微服务拆分方法论别为了拆而拆微服务面试题里“你们项目为什么拆成这些服务”“拆分依据是什么”是典型的开放式问题。如果回答“因为要微服务化所以拆”基本就凉了。正确的思路是从业务边界和团队结构出发。我做过的拆分设计里遵循的核心原则是“高内聚、低耦合”边界优先按业务领域划分而不是按技术层划分。比如一个电商系统通常拆成用户、商品、订单、库存、支付、营销六个核心服务每个服务拥有独立的数据库服务之间通过API或消息通信。这里面有个容易被忽略的点库存和订单的边界怎么划如果订单创建时直接扣减库存那库存其实被订单服务绑架了合理的做法是订单服务发“订单创建事件”库存服务消费事件后扣减这样两个服务解耦也方便后续支撑秒杀等复杂场景。推荐参考的热词里有“微服务架构图”和“微服务拆分”我建议准备面试时亲手画一张你项目的架构图包括服务划分、调用关系、中间件依赖、数据存储。这张图的价值有两层一是帮你自己理清思路面试时能顺手画给面试官看二是很多面试官会在白板上让你画架构图现场画得条理清楚比单纯用嘴说强太多。还要多说一句微服务不是银弹。有些项目单体架构就能搞定硬拆成微服务反而引入分布式事务、链路追踪、服务治理一堆复杂度这是典型的过度设计。面试时可以主动谈一谈“什么场景不适合微服务”比如团队规模小、业务处于验证期的项目拆了反而拖慢交付速度。这种有取舍的表达会让面试官觉得你有架构判断力而不只是会背概念。3.2 注册中心与配置中心选型Nacos、Consul、Eureka怎么选注册中心是微服务的基础设施面试必问。常见的选项有Eureka、Consul、Nacos、Zookeeper现在国内大厂基本上是Nacos和Consul为主Eureka已经进入维护期Zookeeper更适合做分布式协调而不是注册中心。我推荐准备面试时重点掌握Nacos因为它在国内互联网公司的普及率最高而且它同时承担了注册中心和配置中心的职责。Nacos的核心知识点包括临时实例用临时节点非持久化存储通过心跳保活默认5秒上报一次15秒没上报标记为不健康30秒剔除持久化实例则通过主动注册和注销来管理生命周期。这里有个经常考的细节服务下线后消费者为什么短时间内还能调到这个实例这是因为消费者本地有缓存的服务列表还需要等推送或拉取机制触发更新。Nacos通过UDP推送加定时拉取双机制来保证服务列表的最终一致性但极端情况下仍然有短暂的不一致窗口。在面试中能把“不一致窗口”讲出来并且说清楚它是怎么缩小的就很能体现实战经验。配置中心方面Nacos Config的核心是监听机制和MD5校验配置变更后服务端推送事件给客户端客户端刷新上下文。如果配置没生效排查方向一般是是否引入了config依赖、dataId和group是否匹配、是否开启了自动刷新。我踩过最典型的坑是bootstrap.yml和application.yml的优先级问题Spring Cloud 2020.0版本之后默认不再从bootstrap读取配置需要在pom里额外引入spring-cloud-starter-bootstrap才行这个问题不看文档很容易卡半天。3.3 分布式事务Seata与补偿方案的取舍分布式事务是微服务面试中难度最高、也最能拉分的一类题。先理解为什么难微服务拆分后一个业务操作可能跨多个服务、多个数据库本地事务的ACID没法跨服务保证所以需要分布式事务方案。面试时首先要能分清几种方案的适用场景。两阶段提交2PC适合强一致性场景但性能和可用性都差因为协调者单点和同步阻塞问题很明显。三阶段提交3PC做了改进引入了超时和准备阶段但工程落地依然复杂。TCC是一种业务层面的补偿方案通过Try、Confirm、Cancel三个方法保证最终一致性性能比2PC好但侵入性强需要业务方实现三套方法。基于消息的最终一致性方案是业界用得最多的核心思想是“本地消息表 消息重试 幂等消费”适合订单、支付这类对实时性要求不高但必须保证最终一致的场景。在国内面试里Seata是一个绕不开的话题。Seata支持AT模式、TCC模式、SAGA模式其中AT模式最常用它通过全局锁和undo_log日志实现“自动补偿”。AT模式的原理可以简化理解事务开始时Seata记录数据的修改前镜像和修改后镜像如果分支事务失败就用undo_log回滚。这种模式对业务代码侵入小但要注意它在并发写场景下性能下降明显且不支持独立于全局事务的场景。我面试时的建议是不要试图把几种方案都讲得很深而是挑一个你真正落地过的方案讲透。比如你说项目里用了Seata的AT模式就要能说清楚全局事务的commit和rollback流程还要能回答“AT模式会不会产生脏读”“全局锁是什么时候释放”“如果TC宕机怎么办”这类追问。如果没有实际用过Seata也可以诚实说“我们用的是消息最终一致性方案因为业务允许短暂不一致”然后展开讲消息方案的细节这也完全能过关。3.4 服务治理限流熔断与链路追踪服务治理相关的问题这几年考得越来越细。限流、熔断、降级这三个概念容易被混在一起说面试时要能区分清楚。限流是控制请求速率防止系统过载熔断是当依赖服务故障达到阈值时快速失败避免级联崩溃降级是主动牺牲非核心功能保证核心链路可用。实现方面国内主流是Sentinel和Resilience4j。Sentinel是阿里开源、国内用得最多的它的核心概念是资源、规则和Slot执行链。计算限流时Sentinel默认用滑动窗口计数器也可以切换成令牌桶或漏桶算法。面试官如果问“滑动窗口和固定窗口的区别”要能答出固定窗口存在临界突发问题比如0到1秒的最后一刻和1到2秒的第一刻各来1000个请求2秒内实际可能放行2000个而滑动窗口按照细粒度统计可以避免这个问题。链路追踪也是微服务的高频考点。核心理论是Dapper论文里的Span和Trace概念一个分布式调用链由多个Span组成每个Span记录一次跨服务调用的起止时间和父子关系。工程上常用的有SkyWalking、Zipkin和Jaeger。实现思路是每个服务生成traceId和spanId通过HTTP头的透传串联整条调用链日志里打印traceId排查问题时用traceId去检索所有相关日志。这里有一个实际经验想分享光有链路追踪工具还不够一定要把traceId跟业务单据号关联起来。我们线上排查订单问题时都是先根据订单号查出traceId再去检索整条链路否则在海量日志里找一条调用链如同大海捞针。4. AI技术栈与Java后端的结合新考点的破局思路4.1 Java工程师为什么突然要会AI这两年的Java面试里AI相关的问题不再是加分项而是逐渐变成必选项。原因很好理解大厂内部几乎都在用大模型改造业务和研发流程Java后端是最贴近业务的技术栈自然要承接大模型的接入、编排和稳定服务。但不少Java工程师对AI的印象还停留在“Python才是搞AI的语言”一听到AI面试题就先慌了。实际上后端工程师用Java对接大模型核心不在于训练模型而在于工程化能力。你要做的是把模型API接入现有业务系统做好鉴权、限流、超时、重试、缓存、流式输出这些后端基本功再配合提示词工程和知识库检索把模型能力变成稳定可用的产品功能。这套东西的难点在工程架构不在算法恰恰是Java工程师的强项。面试官在这一块通常不会考你推导Transformer公式更多是考你“怎么设计一个AI功能的技术方案”。比如“如果要在你们电商系统的客服模块接入大模型你会怎么设计”这个开放题的核心考点是能不能说清楚请求链路、上下文管理、成本控制、安全审核、兜底策略。只要你的回答里包含这几个维度哪怕细节不完美面试官也会认可你的工程思维。4.2 Java项目接入大模型的核心链路Java接入大模型的标准姿势是通过HTTP调用大模型API。OpenAI兼容接口是事实标准国内的大模型服务也大都提供兼容接口所以Java侧可以统一封装。开发时常用的SDK有Spring AI、LangChain4j以及各家模型厂商官方提供的Java SDK其中Spring AI因为跟Spring Boot生态无缝集成国内后端团队用得越来越多。Spring AI的用法可以简化理解先引入依赖然后在配置类里配置模型API的base-url、api-key和模型名称再通过ChatClient或ChatModel调用对话接口。一个最简单的聊天接口大概是这样Service public class ChatService { private final ChatModel chatModel; public ChatService(ChatModel chatModel) { this.chatModel chatModel; } public String chat(String userMessage) { return chatModel.call(userMessage); } }真实生产环境远没有这么简单。首先要处理流式输出用WebFlux或SSE把大模型的流式响应推给前端否则用户要等全部内容生成完毕才能看到体验很差。其次要考虑超时和重试大模型服务的响应时间波动很大超时设置和重试策略直接决定接口稳定性。我的建议是连接超时设3到5秒读取超时设60秒以上重试最多两次并且要退避避免同时重试把模型服务打爆。还要考虑成本控制每轮对话都会消耗Token如果业务量大了成本会很高。通常的做法是加一层Redis缓存对重复问题直接返回缓存结果再给不同用户设置不同的频次限制对于日志和分析类场景用便宜的模型对用户体验敏感的场景才用强模型。这些细节在面试中讲出来面试官会明显觉得你有真实落地的经验。4.3 RAG与向量检索让模型“懂”你的业务数据大模型有个天然缺陷它只学到训练数据截止时刻的通用知识不知道你公司的内部数据。解决这个问题的主流方案是RAG检索增强生成流程可以概括为四步把业务文档切分成Chunk用Embedding模型转成向量存入向量数据库用户提问时也转成向量做相似度检索把检索到的TopK文档片段和用户问题一起拼进Prompt模型基于这些上下文生成回答。这一步的工程细节非常多。文档切分是第一个坑切太大导致检索粒度粗、Token消耗大切太小导致语义碎片化、召回效果差。我的经验是中文场景下按500到800字切分同时保留100字左右的重叠防止语义在切分处断裂。Embedding模型选型也要考虑中文效果和部署成本如果数据量不大直接用API调用Embedding模型就行没必要自建。向量数据库方面常见的有Milvus、Qdrant、Weaviate也有很多人直接用Redis Search或Elasticsearch的向量检索能力来降低运维成本。Java侧可以通过Spring AI的VectorStore抽象来屏蔽底层差异代码层面增删改查都很简单难点主要在索引参数调优和数据同步的Pipeline。面试中如果聊到RAG建议往深处讲一个点怎么解决检索质量差的问题。可以提混合检索把向量检索和关键词检索结合起来再通过重排模型Rerank对候选结果二次排序还可以提多路召回从不同数据源各召回一批候选合并后统一截断。能讲到这个深度基本就超过九成候选人了。4.4 大模型应用开发的多模态与Agent趋势除了聊天和RAG面试里还可能出现更新的AI考点比如Function Calling和Agent。Function Calling工具调用是我们让模型具备执行动作能力的关键。原理是给模型声明一批函数的名称、参数和描述模型在回答时判断需要调用哪个函数返回结构化的调用请求由后端执行业务逻辑后把结果反馈给模型再生成最终回复。举例来说让大模型帮用户查天气模型自己不会查但可以触发一个查询天气的Function拿到结果再回答用户。Java侧实现时可以用Spring AI的Tool注解把业务方法暴露给模型框架自动处理JSON Schema的声明和调用分发。Agent则是更进一层的概念在一个复杂任务里模型通过“思考-调用工具-观察结果-再思考”的循环自主完成任务。面试中不需要把Agent框架源码讲得多透但要说清楚它的局限和成本。我见过不少项目把Agent用在了不该用的场景对话轮次一多Token成本飙升而且一旦模型在某个步骤返回了错误格式整个链路就会卡死。所以我的建议是能用单轮Function调用解决的就别引入Agent把复杂的Agent能力限定在特定场景里。另外多说一句面试聊AI时一定要带上对技术方案的批判性思考。比如“RAG方案里如果检索到的文档本身有问题模型会被误导怎么办”这种问题没有标准答案但能展示你的判断力远比机械背诵概念加分。5. 实战中的高频问题与避坑技巧5.1 手撕算法的边界与策略大厂Java面试里手撕算法的环节一般避免不了。热词里有冒泡排序、Java排序、sort函数用法这类搜索词看得出很多人在算法这部分花了不少精力。给你一个现实建议面试前把高频题型刷透比追求题海战术有效得多。高频题型主要集中在几个类别数组与双指针、链表反转与合并、二叉树遍历、动态规划入门、TopK问题。Java语言准备的关注点和其他语言不太一样比如用PriorityQueue做TopK就比手写快排容易得多面试时也不要求你用最优解能写出时间复杂度和空间复杂度清晰、边界条件处理完整的解法就够。提一个小技巧写代码前先把思路用注释写出来再逐行实现。这样既能让面试官看懂你的思路也能在自己卡壳时留出思考空间。写完顺手检查两个边界——空输入、单元素输入能避免很多低级失误。还有尽量熟悉一下String、List、Map、数组互换的几个API现场少翻记忆。5.2 场景题的回答套路从“背题”到“解题”现在大厂Java面试里场景题的比例越来越高。典型问法包括“你们的订单超时未支付怎么处理”“如果压测发现接口RT很高你从哪些角度排查”“缓存和数据库一致性问题怎么解决”场景题的回答框架可以归纳成三个层次先定义问题边界再列出可选方案最后结合业务场景做取舍。比如订单超时未支付方案有定时任务扫描、延迟队列RabbitMQ TTL死信队列、Redis过期监听、时间轮算法。不要一上来就说用Redis过期监听因为这个方案有消息丢失和延迟的隐患真正生产环境用得多的是RabbitMQ延迟插件或者定时任务分片扫描。再比如缓存和数据库一致性最稳妥的方案是Cache Aside Pattern加延迟双删关键点是删缓存失败时要靠消息队列重试补偿同时避免并发读把旧数据重新写进缓存。这种回答方式体现出的是一个工程师的决策过程面试官要的就是这个。我自己还有一个习惯准备场景题时用“如果是你负责的系统你会怎么做”来逼自己想细节。比如遇到RT高的问题先看是哪个环节慢——网络网关下游接口数据库还是GC一层层排查把答案从“多线程优化”这种套话变成真正可以落地的排障步骤。5.3 项目经历的包装与表达STAR法则的实战应用项目经历是面试的重头戏也是最容易被低估的一环。很多人技术不错但讲项目时啰嗦半天抓不住重点面试官听着听着就走神了。我的经验是讲项目严格按STAR法则来组织但顺序上要先给结论再补背景。具体来说每个项目准备一个“一分钟电梯介绍”第一句说清楚项目是什么、服务谁第二句讲我的职责和技术栈第三句突出一个难点和我的解法第四句说结果数据。比如说“我负责订单中心重构把单体应用拆成订单、库存、支付三个服务用Seata保证分布式事务一致性上线后接口可用性从99.9%提升到99.99%”这个表达一分钟内让面试官建立完整印象后续追问你再深入展开。项目里一定要准备两个“深挖点”一个是技术难点一个是线上事故。技术难点可以是某个性能瓶颈的排查过程线上事故可以是某次OOM或接口雪崩的处理。讲这两段时多用具体数据支撑比如“QPS从500提升到2000”“GC暂停从200ms降到50ms”数字比形容词有说服力得多。还有一个面试官特别爱问的“如果回到当时你会怎么做得更好”这个问题考察的就是复盘能力不要答“没有已经做得很好了”哪怕是说“当时如果先做容量评估就不会出现OOM”这种简单的反思也比强行完美要加分。5.4 反问环节别浪费这个展示机会面试最后的反问环节很多人随便问一句“公司加班多吗”“业务发展怎么样”就草草结束其实这个环节也可以用来捞分。我建议反问的问题分为两类一类是展示你已有认知的进阶问题比如“团队的微服务治理目前主要用哪些组件有没有在调研新的方案”“AI相关的基础设施比如向量数据库和大模型网关是自研的还是用云上的”另一类是确认你跟岗位匹配度的问题比如“这个岗位主要负责哪条业务线的后端新人在前半年主要参与什么模块”。反问环节本质上也是面试官评估你动机和思考深度的窗口。问得具体、有技术含量会让人感觉到你是认真在考虑这个岗位的结合度而不是海投简历。相反如果对技术问题没有任何追问或者直接说“没有问题”就会丢掉一个展示积极性和思考深度的机会。我个人的经验是准备反问问题时提前了解目标业务线的技术栈如果面试官提到某个技术名词而你恰好研究过顺着追问一句“刚才您说的XX方案我理解是……你们落地时有遇到过XX问题吗”这种互动往往会让面试官面完还愿意给你加分因为聊得好的人技术印象分通常也低不了。最后再分享一点体会面试准备到了后期拼的往往不是知识量而是表达时的松弛感和结构化能力。知识点可以通过刷题补但把知识串联成自己的语言靠的是反反复复的模拟练习。建议考前找一个同级别的同行互相模拟面试一次2小时比你自己闷头背三天都有效。记住面试是双向选择你展示真实水平同时也在判断这家团队适不适合你带着这样的心态上场发挥通常会比紧张兮兮好得多。