配置范式之变：Spring Cloud Alibaba 2025 里 bootstrap.yml 为什么彻底失效

一、症状：一个指向错误的报错

把 user-service 的配置迁移到 Nacos 之后，启动失败：

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to configure a DataSource: 'url' attribute is not specified and
no embedded datasource could be configured.

Reason: Failed to determine a suitable driver class

看到这个报错，第一反应是去查 datasource 配置——但配置文件里明明写着 url。

这个报错本身就在误导人：真正的问题不是"数据库地址没配"，而是"整个 Nacos 配置文件根本没被加载"，datasource 配置自然也就不存在。

那为什么它不直接报"配置没加载"？这后面有一整条因果链。

二、根因一：SCA 2025 不再支持 bootstrap 拉配置

从 Spring Cloud Alibaba 2025.0.0.0 开始，配置加载机制换成了 Spring Boot 的 ConfigData 范式。旧路径被彻底移除——不是"不推荐"，是代码删了。

这一点在 jar 里可以直接验证：

import zipfile

jar = zipfile.ZipFile("spring-alibaba-nacos-config-2025.0.0.0.jar")
names = jar.namelist()

# 搜所有 PropertySourceLocator 的实现
hits = [n for n in names if "PropertySourceLocator" in n]
print(hits)
# 输出：[]      ← 全 jar 里一个都没有

具体变化：

而 NacosConfigBootstrapConfiguration 这个类还在，但它只注册两个 Bean，不再注入任何配置源：

// 只做这两件事，不碰配置加载
@Bean NacosConfigProperties nacosConfigProperties()
@Bean NacosConfigManager nacosConfigManager()

真正干活的是 NacosConfigDataLocationResolver，它的判定逻辑是：

// isResolvable() 只判断两件事
location.hasPrefix("nacos:") && env.getProperty("spring.cloud.nacos.config.enabled", true)

注意：isResolvable() 与 bootstrapEnabled 完全无关。 也就是说，光引入 spring-cloud-starter-bootstrap 并不会让 bootstrap.yml 复活——那个通道已经不存在了。

三、根因二：一个依赖让错误校验静默失效

到这里有个说不通的地方：如果 spring.config.import 缺失，Spring Boot 应该主动报错才对。

确实有这个机制。NacosConfigDataMissingEnvironmentPostProcessor 就是干这个的，它会在 spring.config.import 里没有 nacos 条目时抛异常，防止你"以为配了其实没配"。

但它有个前置判断：

// NacosConfigDataMissingEnvironmentPostProcessor
protected boolean shouldProcessEnvironment(Environment environment) {
    // 如果 bootstrap 被启用，直接跳过校验
    return !PropertyUtils.bootstrapEnabled(environment);
}

再看 PropertyUtils.bootstrapEnabled() 的字节码：

env.getProperty("spring.cloud.bootstrap.enabled", Boolean.class, false)
    || MARKER_CLASS_EXISTS

MARKER_CLASS_EXISTS 是一个类的存在性检查：

private static final boolean MARKER_CLASS_EXISTS =
    ClassUtils.isPresent("org.springframework.cloud.bootstrap.marker.Marker", null);

而这个 Marker 类，就在 spring-cloud-starter-bootstrap-4.2.0.jar 里。

四个服务的 pom 都引入了这个依赖，于是：

引入 spring-cloud-starter-bootstrap
  → Marker 类存在于 classpath
  → bootstrapEnabled() 恒为 true
  → shouldProcessEnvironment() 恒为 false
  → import 防呆校验被静默跳过
  → 配置没加载，但没有任何报错
  → 一路走到 DataSource 才暴露

判据

spring-cloud-starter-bootstrap 是一把双刃剑。 它在旧范式下是必需品，但在 SCA 2025 里，它唯一的作用是让配置缺失的校验失效——把你从"启动即报错"变成"启动成功但行为诡异"。

本项目四个服务的 pom 都还留着这个依赖。迁移完成后应该评估移除，以恢复这个防呆机制。

四、修复：改用 ConfigData 范式

api-cloud-service-user/src/main/resources/application.yml：

spring:
  application:
    name: user-service
  config:
    import:
      - nacos:user-service.yml?group=LFZXW
      - nacos:user-service-dev.yml?group=LFZXW
  cloud:
    nacos:
      config:
        server-addr: ${NACOS_ADDR:127.0.0.1:8848}
        namespace: ${NACOS_NAMESPACE:}
        file-extension: yaml
      discovery:
        server-addr: ${NACOS_ADDR:127.0.0.1:8848}
        namespace: ${NACOS_NAMESPACE:}

server:
  port: 8081

同时把 bootstrap.yml 清空为占位说明——保留文件但不再使用，避免后来的人以为它还在生效。

三个必须注意的点

① 禁用 ${spring.profiles.active} 占位符

# ❌ 错误：解析时机早于 profile 激活
- nacos:user-service-${spring.profiles.active}.yml?group=LFZXW

# ✅ 正确：写显式 profile 名
- nacos:user-service-dev.yml?group=LFZXW

ConfigData 的解析发生在 profile 激活之前，此时 ${spring.profiles.active} 要么解析失败、要么拿到错的值。而且失败方式是静默不加载配置——又是那种最难查的故障形态。

本项目后来在网关的 application.yml:20 里发现了这样一行残留：

- optional:nacos:gateway-service-${spring.profiles.active}.yml?group=LFZXW

违反了已固化的约定。因为网关本来就没有独立配置、且带 optional: 前缀，暂时没造成故障，但已经记入待改清单。

② 同名文件的后置优先级

- nacos:user-service.yml?group=LFZXW        # 基础配置
- nacos:user-service-dev.yml?group=LFZXW    # profile 配置，优先级更高

列表里靠后的覆盖靠前的。所以 Nacos 上必须同时存在这两个 dataId，否则第二个会报 does not exist。

③ optional: 前缀决定是强依赖还是弱依赖

# 业务服务：非 optional = 强依赖，Nacos 上没这条配置就启动失败
- nacos:user-service.yml?group=LFZXW

# 网关：optional = 弱依赖，没有也能启动
- optional:nacos:gateway-service.yml?group=LFZXW

三个业务服务都用非 optional，这是有意的：配置缺失就该立刻失败，而不是带着不完整的配置跑起来。

五、排查这类问题的正确顺序

本次真正的教训是一套顺序：

① 先确认配置有没有被拉到 → ② 再确认配置内容本身对不对

我当时的顺序是反的：先反复检查 Nacos 上的配置内容，改了好几轮"没用"，最后才发现是配置压根没加载。

而第二层坑更隐蔽。配置加载修对之后，问题换了个样子继续存在：应用侧范式改对了，但 Nacos 上的 YAML 把 datasource 缩进到了 server: 下：

server:
  port: 8081
  # ❌ 错误的缩进层级：实际变成了 server.datasource.url
  datasource:
    url: jdbc:mysql://...

实际生效的 key 是 server.datasource.url，而不是 spring.datasource.url——配置被拉到了，但内容路径是错的，表现依然是"改了没用"。

所以两步要分开验证，不能混在一起猜。

六、复盘

四个层次，全部表现为"改了没用"或"报错指向别的地方"。 这就是为什么配置类问题特别耗时间——它的错误信息永远不指向真正的原因。

三条可复用的经验：

1. 升级 Spring Cloud Alibaba 到 2025+ 时，第一件事是检查 spring.config.import，并把 bootstrap.yml 清空（不是删除，是清空并留说明，否则后来的人会继续往里写）。
2. spring-cloud-starter-bootstrap 迁移完就删。 它在新范式下的唯一作用就是让防呆失效。
3. 配置类问题必须分层验证：先证明"配置被拉了"（看日志、看 /actuator/env），再证明"内容对"（对比 Nacos 原文与预期）。