在Java后端面试中，Hutool工具类（尤其是Excel/Word批量导入导出）和JWT（令牌认证）是高频考点，覆盖初级到高级工程师面试场景。Hutool是后端开发中提升效率的“利器”，解决办公文档批量处理的痛点；JWT是前后端分离架构中身份认证的核心方案，两者都是企业实战中不可或缺的技术。

本文整理了两大技术的高频面试题，按“模块划分+考点拆解+实战解析+延伸补充”的结构编写，每个题目均贴合企业真实面试场景，避开理论空谈，重点突出面试官关注的“底层逻辑+实战踩坑+优化方案”，既适合面试备考，也适合日常技术复盘，质量对标一线互联网面试标准，助力大家快速掌握核心知识点，轻松应对面试。

第一模块：Hutool工具类（Excel/Word批量导入导出）

核心考点：Hutool的核心优势、Excel/Word批量导入导出的实现逻辑、异常处理、性能优化，是初级/中级面试必问，重点考察“实战应用能力”。

一、基础认知类（必问，考察基础功底）

1. 什么是Hutool？它在Excel/Word批量导入导出场景中，相比POI有什么优势？

考点解析：考察Hutool的核心定义，以及与传统POI的区别，重点突出Hutool的“简化开发”优势，面试官常延伸问“项目中为什么选择Hutool而非原生POI”。

核心答案：

Hutool是一款Java工具类库，封装了Java开发中常用的工具方法（如字符串处理、日期工具、IO操作、办公文档处理等），核心目标是“简化开发、提高效率”，无需重复编写冗余代码。其中，Hutool的hutool-poi模块专门用于Excel、Word等办公文档的导入导出，底层封装了Apache POI，解决了原生POI的诸多痛点。

Hutool相比原生POI的核心优势：

• 开发效率极高：原生POI代码繁琐（如Excel导入需手动创建Workbook、Sheet、Row、Cell，处理单元格格式、类型转换），而Hutool提供了简洁的API，一行代码即可实现批量导入导出，无需关注底层细节。

• 兼容性强：自动适配Excel 2003（.xls）和2007+（.xlsx）格式，无需手动判断文件类型，避免原生POI中不同格式需使用不同API的问题。

• 异常处理更友好：Hutool封装了常见的文档处理异常（如文件格式错误、单元格为空、数据类型不匹配），可快速定位问题，而原生POI异常信息杂乱，排查难度大。

• 内置常用功能：支持批量导入导出、单元格格式设置（字体、颜色、对齐方式）、数据校验、表头映射（实体类与Excel表头对应），无需额外封装工具类。

• 轻量无依赖：Hutool依赖少，仅需引入核心jar包，无需额外导入大量依赖，而原生POI需导入多个jar包，易出现版本冲突。

延伸补充：项目中使用Hutool处理Excel/Word，需引入hutool-poi依赖（Maven/Gradle），如果是Spring Boot项目，可直接引入hutool-spring-boot-starter，自动集成相关功能。

2. Hutool处理Excel批量导入的核心流程是什么？需要注意哪些细节？

考点解析：考察Hutool的实战应用，重点是导入流程和细节处理，面试官常结合项目场景提问，判断候选人是否有实际开发经验，属于中级必考题。

核心答案：

Hutool处理Excel批量导入的核心流程（以Spring Boot项目为例），分为5步，兼顾效率和异常处理：

1. 引入依赖：在pom.xml中引入hutool-poi依赖，确保版本兼容（推荐5.x版本，适配Java 8+）。 

2. 定义实体类：创建与Excel表头对应的实体类，通过@Excel注解映射表头（如Excel表头“用户姓名”对应实体类的userName字段）。

3. 接收前端上传的Excel文件：通过MultipartFile接收前端上传的文件，判断文件格式（.xls/.xlsx），避免非法文件。

4. 调用Hutool API批量导入：使用ExcelUtil.getReader()创建Excel读取器，指定实体类，读取Excel数据并转换为实体类列表。

5. 数据校验与异常处理：对导入的数据进行校验（如手机号格式、必填项），处理空值、数据类型不匹配等异常，返回友好提示。

需要注意的核心细节：

• 跳过表头：Excel的第1行通常是表头，读取时需指定从第2行开始（index=1，Hutool索引从0开始），避免将表头读取为数据。

• 文件格式校验：必须判断文件后缀，防止上传非Excel文件（如.txt、.doc）导致异常。

• 资源释放：ExcelReader使用后必须关闭（close()），避免IO资源泄漏。

• 数据类型转换：日期、数字等类型需指定格式（如@Excel注解的format属性），否则会出现类型转换异常。

• 大数据量处理：如果导入Excel数据量较大（万级以上），需分批次读取，避免内存溢出。

3. Hutool处理Excel批量导出的核心流程是什么？如何设置导出格式（字体、颜色、列宽）？

考点解析：与导入对应，考察导出的实战能力，重点是格式设置和大数据量处理，面试官常问“如何优化大数据量导出的性能”。

核心答案：

Hutool处理Excel批量导出的核心流程，分为4步，支持自定义格式，适配不同业务需求：

1. 准备导出数据：从数据库查询需要导出的数据，转换为与Excel表头对应的实体类列表（与导入的实体类一致，复用@Excel注解）。

2. 创建Excel写入器：使用ExcelUtil.getWriter()创建写入器，指定导出格式（.xls/.xlsx），默认是.xlsx格式。

3. 设置导出格式（可选）：通过WriterSetting设置字体、颜色、列宽、表头样式等，提升导出文件的可读性。

4. 写入数据并下载：将实体类列表写入Excel，通过response响应给前端，实现浏览器下载。 

延伸补充：如果需要导出多个Sheet，可使用writer.setSheet()切换Sheet，分别写入不同数据；如果导出数据量较大（万级以上），可使用ExcelWriter的分批次写入功能，或使用Hutool的BigExcelWriter，避免内存溢出。

4. Hutool处理Word批量导入导出的核心API有哪些？与Excel处理有什么区别？

考点解析：考察Hutool对Word的处理能力，避免候选人只掌握Excel处理，忽略Word场景，属于中级拓展题。

核心答案：

Hutool处理Word的核心模块是hutool-poi中的WordUtil，支持Word的批量导入（读取）和导出（生成），核心API和流程与Excel类似，但因Word文档结构（段落、表格、图片）更复杂，处理逻辑有差异。

（1）核心API（Word批量导入/导出）：

• Word导入（读取）：

  • WordUtil.getReader()：创建Word读取器，支持.doc和.docx格式。

  • reader.readText()：读取Word中的所有文本内容（适合纯文本读取）。

  • reader.readTables()：读取Word中的所有表格，转换为List<List<String>>（适合表格数据批量导入）。

• Word导出（生成）：

  • WordUtil.getWriter()：创建Word写入器，支持.docx格式（推荐）。

  • writer.addText()：添加文本内容（支持设置字体、颜色、对齐方式）。

  • writer.addTable()：添加表格，支持设置表格样式、单元格格式。

  • writer.flush()：将内容写入流，实现下载或保存。

（2）Word与Excel处理的核心区别：

对比维度	Excel处理（Hutool）	Word处理（Hutool）
核心场景	结构化数据（表格）的批量导入导出，如用户数据、订单数据	非结构化数据（文本、表格、图片）的生成/读取，如合同、报表、简历
API设计	支持实体类映射（@Excel注解），自动匹配表头与实体字段	无实体类映射，需手动处理文本、表格，灵活性更高
大数据量处理	支持SAX解析、分批次读取，适合10万条+数据	不适合大数据量读取（Word文档结构复杂，SAX解析支持有限），适合小批量、复杂格式生成
格式设置	重点设置单元格、表头样式（列宽、字体、颜色）	重点设置段落、表格、文本样式（行距、缩进、字体、图片插入）

延伸补充：Hutool处理Word的复杂格式（如模板填充、图片插入）时，功能相对简单；如果需要复杂Word模板填充（如合同模板替换变量），可结合FreeMarker或EasyPOI，与Hutool配合使用，提升开发效率。

第二模块：JWT（JSON Web Token）

核心考点：JWT的定义、结构、工作原理、实战应用、安全问题，是前后端分离架构面试的必问内容，覆盖初级到高级，重点考察“安全意识”和“实战落地能力”。

1. 什么是JWT？它的核心作用是什么？与传统的Session认证有什么区别？

考点解析：考察JWT的核心定义和认证逻辑，是JWT面试的开篇题，重点区分JWT与Session的差异，体现对前后端分离架构的理解。

核心答案：

JWT（JSON Web Token）是一种基于JSON的、轻量级的身份认证令牌，用于在客户端和服务器之间传递身份信息，核心作用是“无状态认证”，无需在服务器端存储会话信息，适用于前后端分离、分布式系统、跨域认证场景。

JWT的核心作用：

• 身份认证：客户端登录成功后，服务器生成JWT令牌，客户端后续请求携带令牌，服务器验证令牌合法性，确认用户身份。

• 信息传递：JWT可在令牌中携带少量非敏感信息（如用户ID、角色），减少服务器查询数据库的次数，提升接口性能。

JWT与传统Session认证的核心区别：

对比维度	Session认证	JWT认证
状态存储	有状态，会话信息（Session）存储在服务器端（内存、Redis等）	无状态，令牌存储在客户端（Cookie、LocalStorage），服务器端不存储会话信息
分布式支持	差，需实现Session共享（如Redis集群），否则跨节点无法识别会话	好，无状态，任意服务器节点均可验证令牌，天然支持分布式、微服务
跨域支持	差，Cookie默认不支持跨域，需额外配置（如CORS、Cookie跨域）	好，令牌可放在请求头（Authorization）中，支持跨域请求
性能开销	高，服务器端需存储、查询会话信息，并发高时压力大	低，服务器端仅需验证令牌签名，无需查询存储，性能更优
安全性	较高，SessionID存储在服务器端，客户端仅存储Cookie	依赖签名和过期时间，需做好签名密钥保护、令牌加密，否则易被篡改

延伸补充：JWT的无状态特性，导致令牌一旦生成，无法主动撤销（除非设置短期过期时间），这是JWT的核心缺点，需结合Redis等存储实现令牌黑名单，解决撤销问题。

2. JWT的结构是什么？每个部分的作用是什么？

考点解析：考察JWT的底层结构，是理解JWT工作原理的关键，面试官常让候选人默写JWT结构，或解释每个部分的作用，属于必考题。

核心答案：

JWT由3个部分组成，用英文句点（.）分隔，格式为：Header.Payload.Signature，每个部分都是Base64编码的字符串（注意：Base64是编码，不是加密，可直接解码，因此Payload不能存储敏感信息）。

三个部分的具体作用：

1. Header（头部）：

   1. 核心内容：指定JWT的算法（alg）和令牌类型（typ）。

   2. 示例（JSON格式）：{"alg": "HS256", "typ": "JWT"}

      • alg：签名算法，常用HS256（HMAC SHA256，对称加密）、RS256（RSA SHA256，非对称加密）。

      • typ：令牌类型，固定为JWT。

   3. 作用：告诉服务器，该令牌使用的签名算法和类型，用于后续签名验证。

2. Payload（载荷）：

   1. 核心内容：存储需要传递的非敏感信息，分为“标准声明”和“自定义声明”。

   2. 标准声明（可选，推荐使用）：

      • iss（issuer）：令牌签发者。

      • exp（expiration time）：令牌过期时间（时间戳，单位秒），必填，核心用于令牌过期控制。

      • iat（issued at）：令牌签发时间（时间戳）。

      • sub（subject）：令牌所面向的用户（如用户ID）。

   3. 自定义声明（按需添加）：存储业务相关的非敏感信息，如用户ID、角色、用户名等（如{"userId": 123, "role": "admin"}）。

   4. 注意：Payload是Base64编码，可直接解码，因此不能存储敏感信息（如密码、手机号、身份证号）。

3. Signature（签名）：

   1. 核心内容：对Header和Payload进行签名，确保令牌不被篡改。

   2. 签名算法（以HS256为例）：HMACSHA256(base64UrlEncode(Header) + "." + base64UrlEncode(Payload), secretKey)

      • secretKey：签名密钥，由服务器保管，必须保密，一旦泄露，令牌可被伪造。

   3. 作用：服务器验证令牌时，会重新计算签名，与令牌中的Signature对比，如果不一致，说明令牌被篡改，拒绝请求。

延伸补充：Base64UrlEncode与普通Base64的区别：Base64UrlEncode会将Base64中的“+”替换为“-”，“/”替换为“_”，去掉末尾的“=”，避免URL传输时出现特殊字符问题。

3. JWT的工作流程是什么？（结合前后端分离场景说明）

考点解析：考察JWT的实战应用流程，结合前后端分离场景，体现候选人的实战理解，属于初级/中级必考题。

核心答案：

JWT在前后端分离场景中的工作流程，分为5步，全程无状态，适配分布式架构：

1. 客户端发起登录请求：用户输入用户名、密码，前端将数据发送到后端登录接口（如POST /login）。

2. 服务器验证身份并生成JWT：

   1. 后端接收请求，查询数据库，验证用户名、密码是否正确。

   2. 验证通过后，生成JWT令牌（设置Header、Payload、Signature），其中Payload包含用户ID、角色等非敏感信息，exp设置合理的过期时间（如1小时）。

   3. 服务器将JWT令牌返回给前端（通常放在响应体中，如{"code":200, "data":{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}"）。

3. 前端存储JWT令牌：前端将令牌存储在LocalStorage、SessionStorage或Cookie中（推荐LocalStorage，避免Cookie跨域问题）。

4. 客户端发起后续请求：前端每次请求（除登录外），都在请求头中携带JWT令牌，格式为：Authorization: Bearer 令牌。

5. 服务器验证JWT令牌并响应：

   1. 后端拦截所有需要认证的请求（如通过拦截器、过滤器），获取请求头中的JWT令牌。

   2. 服务器验证令牌：① 验证签名（使用secretKey重新计算签名，与令牌中的Signature对比）；② 验证令牌是否过期（对比exp与当前时间戳）；③ 验证令牌签发者、用户信息是否合法。

   3. 验证通过：解析Payload中的用户信息，执行后续业务逻辑，返回响应结果。

   4. 验证失败（如令牌篡改、过期）：返回401（Unauthorized），提示用户重新登录。

延伸补充：JWT的无状态特性，意味着服务器端无需存储任何会话信息，因此在分布式系统中，多个服务器节点均可验证令牌，无需实现会话共享，极大简化了分布式架构的部署。

4. JWT的签名算法HS256和RS256有什么区别？项目中如何选择？

考点解析：考察JWT的安全特性，区分对称加密和非对称加密，是中级/高级面试的重点题，体现候选人的安全意识。

核心答案：

HS256和RS256是JWT最常用的两种签名算法，核心区别在于“签名密钥的使用方式”，一种是对称加密，一种是非对称加密，安全性和使用场景不同。

两者的核心区别：

对比维度	HS256（HMAC SHA256）	RS256（RSA SHA256）
加密类型	对称加密：签名和验证使用同一个密钥（secretKey）	非对称加密：签名使用私钥（privateKey），验证使用公钥（publicKey）
密钥管理	简单，仅需保管一个密钥，但密钥必须严格保密，一旦泄露，令牌可被伪造	复杂，需生成公钥和私钥，私钥保密，公钥可公开（如分发给客户端、其他服务）
安全性	较低，密钥一旦泄露，整个系统的JWT都可被伪造，适合单机、内部系统	较高，私钥仅在服务器端保管，公钥公开，即使公钥泄露，也无法伪造令牌，适合分布式、跨服务场景
性能	较高，对称加密算法简单，签名和验证速度快	较低，非对称加密算法复杂，签名和验证速度比HS256慢
适用场景	单机应用、内部管理系统、对安全性要求不高的场景	分布式系统、微服务、跨服务认证、对安全性要求高的场景（如支付、用户认证）

项目中的选择建议：

• 如果是小型单机应用、内部管理系统，对安全性要求不高，追求性能，选择HS256，简化密钥管理。

• 如果是分布式系统、微服务、跨服务认证，或对安全性要求高（如用户登录、支付相关），选择RS256，通过公钥私钥分离，提升安全性。

• 补充：Spring Boot项目中，可使用jjwt（JWT for Java）工具类，快速实现HS256和RS256的签名与验证。

5. JWT实战中，有哪些安全隐患？如何防范？

考点解析：考察JWT的安全应用能力，是高级面试的重点题，体现候选人的安全意识和实战踩坑经验，面试官常结合实际攻击场景提问。

核心答案：

JWT的安全隐患主要集中在“令牌泄露、篡改、过期管理、敏感信息泄露”等方面，针对每个隐患，有对应的防范措施，具体如下：

1. 隐患1：令牌泄露（最常见）

   1. 风险：JWT令牌被第三方窃取后，可冒充用户身份发起请求，导致信息泄露、恶意操作。

   2. 防范措施：

      • 使用HTTPS协议：加密传输，防止令牌在传输过程中被窃取（如抓包）。

      • 合理存储令牌：前端避免将令牌存储在Cookie中（易被CSRF攻击），优先存储在LocalStorage/SessionStorage，同时设置httpOnly、secure属性（Cookie场景）。

      • 缩短令牌过期时间：如设置1小时内过期，减少令牌泄露后的风险窗口。

      • 添加IP绑定（可选）：令牌中添加用户登录IP，验证时对比当前请求IP，不一致则拒绝（适合对安全性要求极高的场景，如支付）。

2. 隐患2：令牌篡改

   1. 风险：第三方篡改Payload中的信息（如修改用户角色为admin），或伪造令牌，冒充用户。

   2. 防范措施：

      • 使用安全的签名算法：优先使用RS256非对称加密，避免使用HS256（密钥泄露风险高）。

      • 严格保管签名密钥：HS256的secretKey、RS256的privateKey，必须存储在服务器端，避免泄露（如使用配置中心、加密存储）。

      • 添加签名校验：服务器端验证令牌时，必须校验签名，不一致则拒绝请求。

3. 隐患3：Payload存储敏感信息

   1. 风险：Payload是Base64编码，可直接解码，若存储敏感信息（如密码、手机号），会导致信息泄露。

   2. 防范措施：

      • Payload仅存储非敏感信息：如用户ID、角色、用户名等，敏感信息需通过用户ID查询数据库获取。

      • 对Payload进行加密（可选）：如果必须存储敏感信息，可对Payload进行额外加密（如AES加密），再进行Base64编码。

4. 隐患4：令牌无法主动撤销（前文已提，补充防范）

   1. 风险：用户注销、密码修改后，旧令牌仍有效，可能被恶意使用。

   2. 防范措施：结合Redis维护令牌黑名单，实现令牌主动撤销（详见上一题）。

5. 隐患5：CSRF攻击（Cookie存储令牌场景）

   1. 风险：如果令牌存储在Cookie中，第三方网站可通过CSRF攻击，利用用户的Cookie发起请求，冒充用户。

   2. 防范措施：

      • 避免将令牌存储在Cookie中，优先使用请求头携带。

      • 若必须使用Cookie，设置httpOnly（禁止前端JS访问Cookie）、secure（仅HTTPS传输）、SameSite（限制跨域请求携带Cookie）属性。

      • 添加CSRF令牌：前端请求时，携带CSRF令牌，服务器端验证，防止CSRF攻击。