Spring Boot 4.1.0 震撼发布！新特性，惊爆了！

Java精选面试题（微信小程序）：5000+道面试题和选择题，真实面经，简历模版，包含Java基础、并发、JVM、线程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架构设计、大厂真题等，在线随时刷题！

我昨天看到 Spring Boot 4.1.0 正式发布，第一反应不是「又升级了」，而是 Spring 这条线真的进入新阶段了。

Spring Boot 4.0 已经把底座换了一轮：Spring Framework 7、Jakarta EE 11、Jackson 3、Hibernate 7、AOT、可观测性这些东西都往前推了一大步。4.1.0 不是再来一次大拆大建，它更像是在 4.x 这条新轨道上，把生产环境里最疼的几个点继续补硬。

这次官方 6 月 10 日发布，基于 Spring Framework 7.0.8，还带了一堆依赖升级和安全修复。你要说它有没有那种「一看就炸」的新语法？倒也没有。

但它加的东西都很实在：gRPC 自动配置、HTTP 客户端 SSRF 防护、OpenTelemetry 增强、JPA 后台启动、懒加载 JDBC 连接、Jackson 3 配置更新、Log4j 文件轮转。

好家伙，这不是炫技，这是冲着生产系统来的。

这篇我不想写成发版公告搬运，那玩意儿看着跟产品经理周报似的，没劲。我按一个后端项目真要升级的视角，把几个核心点掰开说，顺手写点代码，咱看看它到底硬在哪里。

gRPC 终于被 Spring Boot 正式拉上桌

我觉得 4.1.0 最值得看的第一个点，就是 Spring gRPC 支持。

以前你在 Spring Boot 里写 gRPC，不是不能写，但基本要靠第三方 starter，或者自己手动配 Server、Channel、拦截器、异常处理。项目一复杂，就开始东拼西凑，整的挺像那么回事，实际排查起来头大。

4.1.0 把 gRPC 服务端自动配置纳进来了。只要类路径里有 gRPC 和 Spring gRPC 相关依赖，并且容器里有BindableServiceBean，Boot 就会自动发现服务、装配 Server、挂全局拦截器、接异常处理。

以前你要自己整一个配置类，端口、服务注册、拦截器顺序，全是手工活。现在这块被 Boot 吃进去了，味儿就对了。

先看一个最小的proto，别一上来就写 Java，gRPC 的协议设计才是第一层门槛。

syntax = "proto3";

package user.v1;

option java_multiple_files = true;
option java_package = "com.example.user.grpc";
option java_outer_classname = "UserApiProto";

service UserService {
  // 按用户 ID 查询用户详情，一元调用：一个请求，一个响应
  rpc GetUser(GetUserRequest) returns (GetUserResponse);

// 批量拉用户资料，服务端流：一个请求，服务端连续吐多条数据
  rpc ListUsers(ListUsersRequest) returns (stream UserSummary);
}

message GetUserRequest {
  string user_id = 1;
}

message GetUserResponse {
  string user_id = 1;
  string nickname = 2;
  int32 level = 3;
}

message ListUsersRequest {
  repeated string user_id = 1;
}

message UserSummary {
  string user_id = 1;
  string nickname = 2;
}

这个协议一出来，Java 代码是生成的，不是你手写的。你真正要写的是业务实现。

@GrpcService
publicclassUserGrpcServiceextendsUserServiceGrpc.UserServiceImplBase {

privatefinal UserApplicationService userApplicationService;

publicUserGrpcService(UserApplicationService userApplicationService) {
        this.userApplicationService = userApplicationService;
    }

@Override
    publicvoidgetUser(GetUserRequest request,
            StreamObserver 

 responseObserver) 
{

// gRPC 层只做协议转换，不要把业务逻辑塞在这里
        // 真正的规则、权限、聚合查询，应该放到应用服务里
        UserDetailuser= userApplicationService.getUser(request.getUserId());

GetUserResponseresponse= GetUserResponse.newBuilder()
                .setUserId(user.id())
                .setNickname(user.nickname())
                .setLevel(user.level())
                .build();

// 一元调用也走 StreamObserver，这是 gRPC 的统一响应模型
        // 先 onNext 写响应，再 onCompleted 结束流
        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }

@Override
    publicvoidlistUsers(ListUsersRequest request,
            StreamObserver 

 responseObserver) 
{

// 服务端流式响应适合大结果集，别一次性组个超大 List 撑爆内存
        for (UserDetail user : userApplicationService.listUsers(request.getUserIdList())) {
            UserSummarysummary= UserSummary.newBuilder()
                    .setUserId(user.id())
                    .setNickname(user.nickname())
                    .build();

// 每循环一次推一条，客户端可以边收边处理
            responseObserver.onNext(summary);
        }

// 这里必须手动结束，不然客户端会一直等，等到怀疑人生
        responseObserver.onCompleted();
    }
}

这里的关键不是@GrpcService看着多酷，关键是 Boot 能自动发现这类服务。你写成 Bean，它就能进 gRPC Server，不用再自己维护一套服务注册逻辑。

配置也开始有 Boot 味儿了。

spring:
  grpc:
    server:
      # 内部服务通信常用独立端口，别跟 HTTP 混在一个入口里瞎糊弄
      port:9090
      enabled:true
    client:
      channel:
        user-service:
          # static 表示固定地址，生产里也可能来自服务发现或网格代理
          target:static://user-service.internal:9090
          inbound:
            message:
              # 防止对面一把塞个超大响应，把客户端内存干穿
              max-size:8MB
            keepalive:
              # 长连接不是永生连接，超时要给清理机会
              timeout:40s

客户端也不是非得手动造 Channel，一坨ManagedChannelBuilder写到每个业务里。逻辑通道能走配置，再用@ImportGrpcClients把 Stub 注册成 Bean，业务侧只拿 Stub 用，这才像个正经生产项目。

@Configuration
@ImportGrpcClients(types = UserServiceGrpc.UserServiceBlockingStub.class)
classGrpcClientConfig {
    // Stub Bean 的创建交给 Spring gRPC，业务代码不要到处手动 new Channel
}

@Service
publicclassUserGrpcClient {

privatefinal UserServiceGrpc.UserServiceBlockingStub userStub;

publicUserGrpcClient(UserServiceGrpc.UserServiceBlockingStub userStub) {
        this.userStub = userStub;
    }

public UserDetail queryUser(String userId) {
        GetUserResponseresponse= userStub.getUser(
                GetUserRequest.newBuilder()
                        .setUserId(userId)
                        .build());

// 客户端这里也别把 proto 对象到处传，最好转成自己领域里的对象
        returnnewUserDetail(
                response.getUserId(),
                response.getNickname(),
                response.getLevel());
    }
}

这套写法的设计方向很明确：通道配置归框架，Stub 生命周期归容器，业务代码只处理强类型调用。

我最喜欢的是异常处理也能统一起来。

@GrpcExceptionHandlerAdvice
classGlobalGrpcExceptionHandler {

@GrpcExceptionHandler(UserNotFoundException.class)
    Status handleUserNotFound(UserNotFoundException ex) {
        // NOT_FOUND 比 UNKNOWN 强太多，调用方能明确知道是资源不存在
        return Status.NOT_FOUND.withDescription(ex.getMessage());
    }

@GrpcExceptionHandler(IllegalArgumentException.class)
    Status handleBadRequest(IllegalArgumentException ex) {
        // 参数错就打 INVALID_ARGUMENT，别让客户端猜半天
        return Status.INVALID_ARGUMENT.withDescription(ex.getMessage());
    }

@GrpcExceptionHandler(Throwable.class)
    Status handleUnknown(Throwable ex) {
        // 兜底异常不要把堆栈细节直接吐给调用方，安全上也不体面
        return Status.INTERNAL.withDescription("服务内部错误");
    }
}

这玩意儿生产里太有用了。HTTP 有@ControllerAdvice，gRPC 也该有自己那套统一兜底。

微服务之间走 gRPC，最怕的就是异常语义乱飞。A 服务返回UNKNOWN，B 服务打日志说「调用失败」，C 服务又重试三次，最后消息队列里堆成粥。

统一异常以后，调用方知道哪些能重试，哪些不能重试，监控也能按状态码分桶。这个技术度一下就上来了，不是贴个注解凑热闹。

SSRF 防护，终于开始管出站请求了

第二个我觉得很硬的点，是 HTTP Client 的 SSRF 防护。

SSRF 这玩意儿，很多后端同学嘴上都知道，写代码时又容易忘。用户传一个 URL，你服务端帮他去请求，结果他传了内网地址、云厂商元数据地址、本机管理端口，你的应用就被当成跳板了。

你说这离谱不离谱。

现在 AI 应用更容易中招。什么「读取远程图片」「总结网页内容」「拉取用户给的文档」「调用第三方 webhook」，全都是出站请求。你要是不拦，别人给你一个http://169.254.169.254/latest/meta-data/，云服务器元数据可能就露馅了。

Spring Boot 4.1.0 引入了InetAddressFilter这类出站地址过滤能力，可以对自动配置的 HTTP 客户端做地址层防护。

我先写一个朴素版，让你看懂这个东西到底在防什么。

@Component
publicclassPrivateNetworkAddressGuard {

publicvoidcheck(String host)throws UnknownHostException {
        InetAddressaddress= InetAddress.getByName(host);

// 127.0.0.1、::1，这种访问本机的地址必须拦
        if (address.isLoopbackAddress()) {
            thrownewIllegalArgumentException("禁止访问本机地址: " + host);
        }

// 10.x、172.16-31.x、192.168.x，这些内网地址也必须拦
        if (address.isSiteLocalAddress()) {
            thrownewIllegalArgumentException("禁止访问内网地址: " + host);
        }

// 169.254.x.x 这种链路本地地址，经常牵扯云厂商元数据
        if (address.isLinkLocalAddress()) {
            thrownewIllegalArgumentException("禁止访问链路本地地址: " + host);
        }

// 组播地址也别放出去，业务请求正常用不上
        if (address.isMulticastAddress()) {
            thrownewIllegalArgumentException("禁止访问组播地址: " + host);
        }
    }
}

这段代码不是让你在 4.1 里手搓替代框架能力，而是先把 SSRF 的风险点讲明白：危险不在 URL 字符串本身，危险在 DNS 解析后的真实 IP。

很多人只校验url.startsWith("https://")，然后觉得稳了。稳个锤子。域名可以解析到内网，DNS 还可能前后两次解析不一样，这里面坑多得很。

业务里常见的 webhook 调用，可以写成这种味道。

@Service
publicclassWebhookPublisher {

privatefinal RestClient restClient;
    privatefinal PrivateNetworkAddressGuard addressGuard;

publicWebhookPublisher(RestClient.Builder builder,
            PrivateNetworkAddressGuard addressGuard) {
        this.restClient = builder.build();
        this.addressGuard = addressGuard;
    }

publicvoidpublish(String callbackUrl, WebhookPayload payload) {
        URIuri= URI.create(callbackUrl);

// 只允许 http/https，file、ftp、jar 这些协议别让它进来整活
        if (!"http".equals(uri.getScheme()) && !"https".equals(uri.getScheme())) {
            thrownewIllegalArgumentException("不支持的回调协议: " + uri.getScheme());
        }

// host 为空的 URL 不要继续请求，后面异常会更难看
        if (uri.getHost() == null) {
            thrownewIllegalArgumentException("回调地址缺少 host");
        }

try {
            // 真正的防护点：请求发出去之前先检查解析后的目标地址
            addressGuard.check(uri.getHost());
        }
        catch (UnknownHostException ex) {
            thrownewIllegalArgumentException("回调域名无法解析: " + uri.getHost(), ex);
        }

restClient.post()
                .uri(uri)
                .body(payload)
                .retrieve()
                .toBodilessEntity();
    }
}

Boot 4.1 的价值就在这里：它想把这种「出站 HTTP 不准乱跑」的能力往标准客户端链路里塞，而不是让每个项目都靠自觉。

我见过太多项目，入站安全搞得像铜墙铁壁，Spring Security、网关鉴权、限流、验证码全上。结果出站请求一放开，用户给啥 URL 它就请求啥 URL。

这个省事，省着省着就出事。

生产里我建议至少定三条规矩：用户可控 URL 必须走白名单或地址过滤；所有出站 HTTP 禁止跟随重定向到内网；超时必须收紧，别让一个烂 URL 拖死工作线程。

全局 HTTP 客户端配置可以先这样兜个底。

spring:
  http:
    clients:
      # 连接超时要短，出站请求不是让你等到海枯石烂
      connect-timeout: 2s
      # 读取超时也要短，慢响应会把线程池一点点耗干
      read-timeout: 3s
      # 重定向尤其要小心，攻击者可以先给公网地址，再跳内网
      redirects: dont-follow

这不是洁癖，这是被线上毒打之后的基本素养。

懒加载 JDBC 连接，事务里少拿没用连接

第三个细节很小，但很工程。

Spring Boot 4.1.0 新增了spring.datasource.connection-fetch，可以把自动配置的连接池DataSource包一层LazyConnectionDataSourceProxy，让物理连接真正需要执行 SQL 时再从池子里拿。

配置就一行。

spring:
  datasource:
    # lazy 表示进事务不立刻拿连接，真正创建 Statement 时才取物理连接
    connection-fetch: lazy

这个东西解决啥？

有些业务方法上挂了@Transactional，但里面不一定每次都访问数据库。比如先查缓存，命中就直接返回；或者先做权限判断，不通过就抛异常；或者先拿分布式锁，锁都没拿到，压根不用碰数据库。

传统方式可能事务一开始就从连接池拿连接，最后发现根本没用上。高并发时这就很亏，亏得冒烟。

@Service
publicclassOrderQueryService {

privatefinal OrderRepository orderRepository;
    privatefinal OrderCache orderCache;
    privatefinal PermissionService permissionService;

publicOrderQueryService(OrderRepository orderRepository,
            OrderCache orderCache,
            PermissionService permissionService) {
        this.orderRepository = orderRepository;
        this.orderCache = orderCache;
        this.permissionService = permissionService;
    }

@Transactional(readOnly = true)
    public OrderDetail queryOrder(String userId, String orderId) {
        // 权限不通过直接抛异常，lazy 模式下不会因为事务开启就先占一个连接
        permissionService.checkCanViewOrder(userId, orderId);

// 缓存命中直接返回，也不会白白占用数据库连接
        OrderDetailcached= orderCache.get(orderId);
        if (cached != null) {
            return cached;
        }

// 走到这里才真正执行 SQL，LazyConnectionDataSourceProxy 才去连接池拿连接
        return orderRepository.findDetail(orderId)
                .orElseThrow(() -> newOrderNotFoundException(orderId));
    }
}

注意，它不是让 SQL 变快，也不是让数据库变强。它解决的是「连接占用时间」这个问题。

数据库连接池是很稀缺的东西，尤其是 Java 应用多、副本多、连接池配置又贼大的时候，数据库那边扛不住。一个服务 50 个连接，20 个副本就是 1000 个连接，你瞅瞅，这还没算别的服务。

再看一个更贴生产的场景。

@Transactional
publicvoidconfirmOrder(String orderId) {
    // 先拿业务锁，避免同一个订单被多个请求同时确认
    // 如果锁竞争很激烈，线程可能在这里等几十毫秒甚至几百毫秒
    lockTemplate.execute("order:" + orderId, () -> {

// lazy 连接模式下，等待锁的时间不会占用 JDBC 连接
        // 真正进入这行查询，才开始从连接池借连接
        Orderorder= orderRepository.findByIdForUpdate(orderId)
                .orElseThrow(() -> newOrderNotFoundException(orderId));

order.confirm();
        orderRepository.save(order);
    });
}

这点我觉得特别实在。因为很多线上连接池被打满，不是 SQL 真跑满了，而是连接被拿得太早、还得太晚，中间夹着缓存、RPC、锁等待、参数校验，全在占坑。

connection-fetch: lazy就是在减少这种无效占坑。

当然也别神化它。如果你的业务方法一进来第一行就是查库，那 lazy 基本没啥收益。它适合那些事务边界比较大、前置逻辑比较多、读多写少、缓存命中率高的系统。

JPA 后台启动，应用冷启动别卡成老牛

4.1.0 里还有个容易被忽略的点：JPA 后台启动。

很多 Spring Boot 项目启动慢，慢在哪里？不一定是业务 Bean 多，有时候是EntityManagerFactory初始化、实体扫描、Hibernate 元数据构建、校验映射关系，一坨东西都在启动主线程里排队。

项目小你没感觉。项目一大，实体几百个，模块一堆，启动日志刷刷刷半天，像拖拉机上坡。

JPA 后台启动的思路很直接：让某些 JPA 初始化工作放到后台线程里跑，别把整个应用启动流程堵死。

spring:
  data:
    jpa:
      repositories:
        # deferred 表示仓库延迟引导，Boot 会用异步执行器参与初始化
        # 目标是别让所有 Repository 初始化都堵在主启动链路上
        bootstrap-mode: deferred

如果你做的是传统 Web 管理后台，启动慢几秒可能无所谓。但如果你上了容器编排、弹性扩缩容、灰度发布，启动时间就是真成本。

Pod 起得慢，滚动发布就慢。健康检查晚通过，流量接入就晚。出了故障要扩容，服务半天起不来，那叫一个恼火。

不过这个能力也别闭眼开。JPA 延迟或后台初始化，会改变一些错误暴露的时间点。以前启动时报映射错误，现在可能变成第一次访问某个 Repository 时才炸。

所以我一般会这样处理：生产可以评估后台启动，但测试环境、预发环境一定要跑完整 Repository 冒烟测试，把实体映射、表字段、查询方法先扫一遍。

@SpringBootTest
classJpaMappingSmokeTest {

@Autowired
    private ApplicationContext applicationContext;

@Test
    voidshouldInitializeAllRepositories() {
        // 把所有 Repository Bean 拉出来触发初始化
        // 目的不是测业务，是尽早暴露 JPA 映射和查询方法错误
        Map 

 repositories = 

                applicationContext.getBeansOfType(Repository.class);

assertThat(repositories).isNotEmpty();
    }
}

这个测试看着土，但是管用。升级框架最怕的不是启动失败，最怕的是启动成功，某个冷门接口第一次被用户点到才失败。

那才叫尬住。

OpenTelemetry 增强，可观测性继续往前拱

Spring Boot 这几年一直在把可观测性往框架底层塞，4.1.0 继续增强 OpenTelemetry 支持。

现在微服务链路一长，排查问题已经不能靠看日志硬猜了。一个请求从网关进来，穿过 HTTP、gRPC、消息队列、数据库，再到下游服务，没 Trace 真不行。

配置 OTLP 导出，大概是这种味儿。

management:
  tracing:
    sampling:
      # 演示环境可以全量采样，生产别无脑 1.0，存储和带宽都会爆
      probability:1.0
opentelemetry:
    tracing:
      export:
        otlp:
          # 常见做法是先打到 OpenTelemetry Collector，再由 Collector 转发
          endpoint:http://localhost:4318/v1/traces
          timeout:10s

我建议你别只满足于「链路能串起来」。真正好用的观测，是业务关键点也能看见。

比如支付链路，你至少要知道订单号、支付渠道、结果状态、耗时分布。订单号这种高基数字段不能乱塞低基数标签，不然指标系统会炸，这个坑很多人踩。

@Service
publicclassPaymentService {

privatefinal ObservationRegistry observationRegistry;
    privatefinal PaymentGateway paymentGateway;

publicPaymentService(ObservationRegistry observationRegistry,
            PaymentGateway paymentGateway) {
        this.observationRegistry = observationRegistry;
        this.paymentGateway = paymentGateway;
    }

public PaymentResult pay(PaymentCommand command) {
        return Observation.createNotStarted("payment.process", observationRegistry)
                // 低基数字段适合做指标标签，比如渠道就那么几个值
                .lowCardinalityKeyValue("channel", command.channel())
                // 高基数字段适合进 Trace，不适合进 Metrics 标签
                .highCardinalityKeyValue("order.id", command.orderId())
                .observe(() -> {
                    // 这里包住真正的支付调用，Trace 里能看到业务段耗时
                    return paymentGateway.pay(command);
                });
    }
}

这段代码看着简单，线上价值很大。

以前排查支付慢，你可能只看到接口耗时 3 秒。现在 Trace 里能看出来，是参数校验 2ms、查订单 15ms、调用支付渠道 2800ms、落库 30ms。责任一下就清楚了，别互相甩锅。

尤其这次 gRPC 被纳入 Boot 生态以后，HTTP 和 gRPC 链路都有机会接到统一观测里。内部服务如果 HTTP、gRPC 混着用，Trace 断点越少，排障越轻松。

再狠一点，你可以给关键异常打事件。

public voidfreezeAccount(String userId, String reason) {
    Observationobservation= Observation.start("account.freeze", observationRegistry)
            .highCardinalityKeyValue("user.id", userId);

try (Observation.Scopescope= observation.openScope()) {
        // 业务执行前记录原因，排查风控问题时很有用
        observation.event(Observation.Event.of("freeze.reason." + reason));

accountRepository.freeze(userId, reason);
    }
    catch (RuntimeException ex) {
        // 异常要进观测上下文，不然 Trace 只显示失败，看不到失败原因
        observation.error(ex);
        throw ex;
    }
    finally {
        observation.stop();
    }
}

当然事件名也别乱来，别把用户手机号、身份证、Token 这种敏感信息塞进去。观测系统不是垃圾桶，啥都往里倒，迟早出事故。

Jackson 3 配置更新，4.x 生态继续清账

Spring Boot 4 这一代还有个大变化：Jackson 3。

4.1.0 继续补 Jackson 配置属性和自定义支持。这个点不如 gRPC 吸睛，但升级时很容易踩坑。

很多老项目里有一堆ObjectMapper自定义：时间格式、枚举序列化、忽略空值、未知字段处理。Boot 4 之后底层包名、默认行为、配置属性都有调整，你不能假设 3.x 项目里的序列化结果原封不动过来。

Jackson 3 里很多包名已经变成tools.jackson。这不是小事，你复制老代码一编译，直接红一片。

如果你想让 Jackson 3 尽量贴近 Spring Boot 以前给 Jackson 2 配的默认行为，可以先看这个属性。

spring:
  jackson:
    # 迁移期可以打开，让 Jackson 3 尽量沿用 Boot 过去对 Jackson 2 的默认配置习惯
    # 但别把它当永久拐杖，核心接口还是要补序列化测试
    use-jackson2-defaults: true

更推荐的方式，是把 JSON 规则集中到一个地方，别让每个模块自己 new 一个 mapper。

@Configuration
publicclassJacksonConfig {


@Bean
    JsonMapperBuilderCustomizer apiJsonCustomizer() {
        return builder -> builder
                // 第三方多返回字段时不要直接炸，接口兼容性会好一点
                .disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
                // 时间统一走 ISO-8601，别一会儿时间戳，一会儿字符串
                .defaultDateFormat(newStdDateFormat())
                // 枚举序列化策略要提前定，不然后面改一次就是接口破坏
                .enable(MapperFeature.ACCEPT_CASE_INSENSITIVE_ENUMS);
    }
}

注意这里的类名和包名要按 Jackson 3 实际依赖来。老的com.fasterxml.jackson.databind.ObjectMapper思路不能照搬到底，4.x 升级时这里最容易骂娘。

我更建议加一组契约测试，把关键接口的 JSON 输出钉死。

@JsonTest
classOrderJsonContractTest {

@Autowired
    private JsonMapper jsonMapper;

@Test
    voidshouldSerializeOrderDetail()throws Exception {
        OrderDetaildetail=newOrderDetail(
                "O-10086",
                OrderStatus.PAID,
                LocalDateTime.of(2026, 6, 15, 21, 30));

Stringjson= jsonMapper.writeValueAsString(detail);

// 这类断言不是为了好看，是为了升级 Jackson 时第一时间发现格式变化
        assertThat(json).contains("\"orderId\":\"O-10086\"");
        assertThat(json).contains("\"status\":\"PAID\"");
        assertThat(json).contains("\"paidAt\":\"2026-06-15T21:30:00\"");
    }
}

很多团队升级框架，单元测试绿了，上线接口却炸了。原因就是以前测试只测对象，不测 JSON 合约。

前端、移动端、第三方系统不关心你内部换了 Jackson 2 还是 Jackson 3，它只关心字段名、枚举值、时间格式有没有变。你把这个搞崩了，人家才不听你解释「我们升级了底层序列化框架」。

Log4j 文件轮转，不是小功能，是保命功能

这次还有 Log4j 文件轮转相关增强，很多人看一眼就划过去了。

我跟你说，日志这东西平时不起眼，线上一出事就变成救命绳。日志文件不轮转，磁盘打满；轮转策略不合理，关键日志被清掉；压缩和保留周期没配好，排查事故时找不到现场。

一个生产项目的日志配置至少要回答三个问题：单个文件多大切，最多保留多久，总量上限是多少。

                             fileName="logs/app.log"
                     filePattern="logs/app-%d{yyyy-MM-dd}-%i.log.gz">
            
                 

                 

             
Policies>
                
                     

                     

                 
Delete>
             
DefaultRolloverStrategy>
         
RollingFile>
     
Appenders>



            
         
Root>
     
Loggers>
 
Configuration>

这段配置不新鲜，但为什么我要放进来？因为框架增强日志轮转能力，说明它继续在补生产细节。

别嫌土。线上磁盘被日志打满，MySQL 写不进去，应用健康检查失败，Pod 一直重启，这种事故真不稀罕。

技术文章都爱讲高大上的架构图，真到生产，很多事故就是日志、连接池、超时、线程池这些脏活没管好。

这次升级到底该不该冲

我觉得 Spring Boot 4.1.0 不是那种「所有项目今晚必须升」的版本。

如果你还在 Spring Boot 2.x，甚至 Java 8、Java 11，那别做梦一步上 4.1。先还技术债，Java 17/21、Jakarta 包名、Spring Framework 7、Hibernate 7、Jackson 3，这些都得过一遍。

如果你已经在 4.0.x，那 4.1.0 很值得评估。它不是换世界观，而是补生产能力。gRPC 正式接入，SSRF 防护加强，OpenTelemetry 更顺，JPA 和 JDBC 细节优化，这些都是真项目会用到的东西。

尤其是这几类项目，我建议重点看：内部服务之间已经开始用 gRPC 的；有 Webhook、远程 URL 抓取、AI 工具调用这类出站 HTTP 的；数据库连接池经常紧张的；正在统一 Trace、Metrics、Logs 的微服务系统。

别看发版公告里每条都不长，组合起来其实挺狠。

我会按这个顺序评估升级：先跑依赖树，看 Java、Jakarta、Hibernate、Jackson 有没有硬冲突；再补 JSON 契约测试，把序列化行为钉住；然后压测 gRPC 和 JDBC 懒连接场景；最后把 Trace、日志、HTTP 出站策略接上。

不是说上来就全开。框架升级最忌讳一把梭，出了问题你都不知道是哪一刀砍的。

我的结论很简单：Spring Boot 4.1.0 开启的不是全新革命，而是 4.x 生产化能力的第一波大补强。

来源：网络

公众号“Java精选”所发表内容注明来源的，版权归原出处所有（无法查证版权的或者未注明出处的均来自网络，系转载，转载的目的在于传递更多信息，版权属于原作者。如有侵权，请联系，笔者会第一时间删除处理！

最近有很多人问，有没有读者交流群！加入方式很简单，公众号Java精选，回复“加群”，即可入群！

文章有帮助的话，点在看，转发吧！