千木一枝的博客

Spring Framework 6.x引入了全新的异常处理机制，通过ProblemDetail和ErrorResponse接口实现异常国际化。ProblemDetail遵循RFC 7807规范，提供标准化的错误响应格式。ErrorResponse是国际化核心接口，支持通过MessageSource自动处理异常消息的多语言转换。开发者可以自定义异常实现这些接口，利用Spring自动生成的国际化消息code（基于完整类名）或自定义消息code。

文章从源码层面详细解析了 ExceptionTranslationFilter、@ExceptionHandler、ResponseEntityExceptionHandler 等核心组件的初始化过程与协作关系，配以清晰的流程图展示异常从抛出到响应的完整链路。同时提供了大量可直接使用的实战代码，包括全局异常处理器、自定义认证入口点、统一错误响应格式等最佳实践。通过本文，您将全面掌握安全异常与业务异常的分层处理策略，构建健壮的应用异常处理体系。

Spring Security在Session序列化策略上经历了从JDK序列化到JSON的演进，但未完全采用JSON主要基于三大考量：1) 安全性需求，Authentication对象需特殊处理敏感凭证；2) 类型完整性，JSON难以处理多态类型；3) 性能与兼容性权衡。实际应用中，推荐使用Kryo序列化方案，它在性能、大小和安全性上取得较好平衡。开发者可自定义RedisSerializer实现，需特别注意确保Token类可序列化并注册相关安全类。

本文详细介绍了Spring Boot 4.0与Spring Security 7中的统一异常处理机制。主要内容包括： Spring Security Filter链的工作原理，重点分析了ExceptionTranslationFilter作为核心异常处理器的作用位置 通过流程图展示了异常处理的完整过程，区分了认证异常和授权异常的不同处理路径 深入解析ExceptionTranslationFilter源码，说明其如何捕获并转换各类异常 解释了为何Controller层异常会被Security过滤器捕获的机制

摘要 Spring Authorization Server 已正式迁移至 Spring Security 7.0，将 OAuth2 和 OpenID Connect 支持深度集成到核心模块中。这一架构变革旨在提供更统一的开发体验、提高维护效率并满足社区需求。主要变化包括：包名重构（如从 org.springframework.security.oauth2.server.authorization 迁移至 org.springframework.security.oauth2.core）、配置类简化（使用

Spring Boot 4 HTTP客户端升级指南 随着Spring Boot 4.0发布，传统的RestTemplate正式被弃用。本文介绍了两种现代HTTP客户端替代方案： WebClient（异步场景首选）： 基于响应式编程 非阻塞I/O模型 适合高并发场景 需要添加spring-boot-starter-webflux依赖 RestClient（同步场景推荐）： Spring 6.1引入 现代化同步API 更简洁的接口设计 使用spring-boot-starter-web依赖 迁移策略建议分阶段进

本文介绍了如何使用OpenRewrite工具将Spring Boot 2升级到4版本。OpenRewrite是一个自动化代码重构工具，能高效处理Spring Boot升级中的包名迁移、配置更新等任务。文章详细说明了升级步骤：首先配置Maven/Gradle插件，通过rewrite:diff预览变更，再执行rewrite:run应用修改，最后手动处理剩余问题。同时提供了升级后的验证方法和常见问题解决方案，如javax到jakarta的包替换、Spring Security配置调整等。文章强调升级前应做好备份和

本文介绍了从Spring Security 5迁移到Spring Security 6/Spring Boot 3的关键步骤。主要内容包括：版本对应关系，Spring Security 6需要Java 17并使用jakarta命名空间；新特性如移除WebSecurityConfigurerAdapter、引入lambda DSL配置；具体迁移过程演示，包括配置类注解更新、WebSecurityCustomizer替代方案等。文章提供了从项目设置到逐步迁移的完整指南，帮助开发者平滑过渡到新版本。

Spring Cloud Gateway 新增WebMVC版本，支持传统Servlet容器部署，解决了WebFlux版本对Netty的依赖问题。WebMVC版本基于Servlet API，兼容现有生态系统，通过JDK21虚拟线程技术实现了接近WebFlux的性能表现。文章对比了两种架构的技术栈、性能指标和适用场景，建议传统企业应用选择WebMVC版本以降低迁移成本，而全栈响应式系统仍适合WebFlux版本。关键区别在于WebMVC支持WAR部署和Servlet过滤器。