spring-cloud-alibaba NacosConfigDataLocationResolver 在未使用 `optional:nacos:` 进行 import 时无法正确注册 NacosConfigManager 实例到 spring 上下文中

问题描述

NacosConfigDataLocationResolver 类主要负责两件事：

注册 NacosConfigManager 到 Spring 的 Bootstrap 上下文中；
加载通过 spring.config.import=optional:nacos:xxx 方式指定的 dataId 配置内容。

当前在 isResolvable() 方法中，存在一个判断逻辑：

if (!location.hasPrefix(getPrefix())) {
    return false;
}

该逻辑会阻止 NacosConfigDataLocationResolver 继续执行 resolveProfileSpecific() 方法，从而导致即使用户没有使用 optional:nacos: 的 import 方式引入配置，NacosConfigManager 也无法被正确注册（即 properties 为默认值）。

问题现象

当用户没有通过 spring.config.import=optional:nacos:xxx 的方式引入配置时，isResolvable() 返回 false，使得 resolveProfileSpecific() 不会被调用，进而导致：

NacosConfigManager 未在 NacosConfigDataLocationResolver 中注册；
最终虽然 NacosConfigAutoConfiguration 会注册一个 fallback 的 NacosConfigManager 实例，但其内部的 NacosConfigProperties 是使用默认值构造的（未绑定配置文件中的属性）；
如果用户希望在代码中通过 NacosConfigManager 获取 ConfigService 进行编程式配置操作，将无法获取到正确配置的实例。

期望行为

即使用户没有使用 optional:nacos: 的 import 方式加载配置，也应该正常注册一个绑定了配置文件属性的 NacosConfigManager 实例，以支持编程式使用场景。

建议修复方案

为 NacosConfigManager 增加 afterProperties 处理，刷新所有配置。因为当 NacosConfigManager 这个 bean 初始化完成之前进行 afterProperties 调用时，整个环境变量中的所有配置都已经全部就绪且为最终的值。

复现步骤

在 application.yml 中配置 spring.cloud.nacos.config.server-addr 等属性；
不使用 spring.config.import=optional:nacos:xxx；
启动应用后，注入 NacosConfigManager，查看其 NacosConfigProperties 是否绑定了配置文件中的属性；
实际结果：属性为默认值（未绑定）；
期望结果：属性正确绑定配置文件中的值。

补充说明

该问题影响所有需要通过 NacosConfigManager 编程式访问 Nacos 配置的场景，即使没有使用 spring.config.import 的方式加载配置，也应该能获取到正确配置的 NacosConfigManager 实例。

Dec 05 '25 06:12 xzxiaoshan

你好，劳烦补充一下 SpringCloudAlibaba 的版本，以方便更快地定位问题哈

Dec 05 '25 07:12 uuuyuqi

你好，劳烦补充一下 SpringCloudAlibaba 的版本，以方便更快地定位问题哈

你好，版本号是：2025.0.0.0

Dec 05 '25 08:12 xzxiaoshan

验证问题，划重点：不要配置 spring.config.import=optional:nacos:xxx 时验证，比如不配置任何 import 的情况下，在 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容。这是一个在日常应用中不太会发现的问题，因为很少会有人刚好没有写 import，但是恰巧不配置任何 import 该问题就出现了。

提交的PR，通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置，这样可以确保 NacosConfigManager 实例中的属性是各种方式传入的最终内容。

请 review ，如果有问题请及时告知我。

Dec 05 '25 09:12 xzxiaoshan

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

Dec 05 '25 09:12 chiangzeon

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

因为如果没有配置任何 import 条目，NacosConfigDataLocationResolver 不会执行（注意 isResolvable 方法做了 hasPrefix 判断）。而 NacosConfigManager 能正确注册，取决于 NacosConfigDataLocationResolver.registerConfigManager 方法。

因为 NacosConfigDataLocationResolver 不会执行，导致自动配置类中默认初始化的 NacosConfigManager 是一个参数不全的 NacosConfigProperties 对象。它里面不会包含可靠的配置文件、启动参数方式传入的所有参数。所以应用程序中注入的这个 NacosConfigManager 就是一个属性可能就是 java 对象默认值的对象（写一个 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容，不做任何 import 的情况下应该能直接发现问题）。

然后我认为，在 NacosConfigManager 的 afterPropertiesSet 方法中获取 environment 中的配置，初始化 NacosConfigManager 的 nacosConfigProperties 属性，也符合 spring 对 afterPropertiesSet 设计的意义。我认为这是一种比较可靠准确解决问题的方式。因为执行 afterPropertiesSet 时，environment 此时是完整包含了所有配置的内容。比如 application.yml 中、通过启动参数传入的、电脑环境变量中配置的，此时 environment 中的 nacos 配置是比较可靠的。

Dec 05 '25 10:12 xzxiaoshan

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

特指 bean 生命周期执行 afterPropertiesSet 这件事，执行完成 afterPropertiesSet 完成后才会将 bean 完整放入 spring 容器中。

Dec 05 '25 10:12 xzxiaoshan

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

因为如果没有配置任何 import 条目，NacosConfigDataLocationResolver 不会执行（注意 isResolvable 方法做了 hasPrefix 判断）。而 NacosConfigManager 能正确注册，取决于 NacosConfigDataLocationResolver.registerConfigManager 方法。

因为 NacosConfigDataLocationResolver 不会执行，导致自动配置类中默认初始化的 NacosConfigManager 是一个参数不全的 NacosConfigProperties 对象。它里面不会包含可靠的配置文件、启动参数方式传入的所有参数。所以应用程序中注入的这个 NacosConfigManager 就是一个属性可能就是 java 对象默认值的对象（写一个 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容，不做任何 import 的情况下应该能直接发现问题）。

然后我认为，在 NacosConfigManager 的 afterPropertiesSet 方法中获取 environment 中的配置，初始化 NacosConfigManager 的 nacosConfigProperties 属性，也符合 spring 对 afterPropertiesSet 设计的意义。我认为这是一种比较可靠准确解决问题的方式。因为执行 afterPropertiesSet 时，environment 此时是完整包含了所有配置的内容。比如 application.yml 中、通过启动参数传入的、电脑环境变量中配置的，此时 environment 中的 nacos 配置是比较可靠的。

但实际运行中，由于NacosConfigDataMissingEnvironmentPostProcessor派生自ConfigDataMissingEnvironmentPostProcessor，shouldProcessEnvironment返回true的情况，会导致后续应用启动失败（结合上述的不加入任何import的条件），这取决于两个属性

spring.cloud.bootstrap.enabled || spring.config.use-legacy-processing 亦或者添加依赖 spring-cloud-starter-bootstrap 这个需要考虑么

另外再确认下最终期望结果，在无任何import配置下，NacosConfigManager能获取当前的全部环境变量是么

Dec 05 '25 10:12 chiangzeon

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

因为如果没有配置任何 import 条目，NacosConfigDataLocationResolver 不会执行（注意 isResolvable 方法做了 hasPrefix 判断）。而 NacosConfigManager 能正确注册，取决于 NacosConfigDataLocationResolver.registerConfigManager 方法。因为 NacosConfigDataLocationResolver 不会执行，导致自动配置类中默认初始化的 NacosConfigManager 是一个参数不全的 NacosConfigProperties 对象。它里面不会包含可靠的配置文件、启动参数方式传入的所有参数。所以应用程序中注入的这个 NacosConfigManager 就是一个属性可能就是 java 对象默认值的对象（写一个 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容，不做任何 import 的情况下应该能直接发现问题）。然后我认为，在 NacosConfigManager 的 afterPropertiesSet 方法中获取 environment 中的配置，初始化 NacosConfigManager 的 nacosConfigProperties 属性，也符合 spring 对 afterPropertiesSet 设计的意义。我认为这是一种比较可靠准确解决问题的方式。因为执行 afterPropertiesSet 时，environment 此时是完整包含了所有配置的内容。比如 application.yml 中、通过启动参数传入的、电脑环境变量中配置的，此时 environment 中的 nacos 配置是比较可靠的。

但实际运行中，由于NacosConfigDataMissingEnvironmentPostProcessor派生自ConfigDataMissingEnvironmentPostProcessor，shouldProcessEnvironment返回true的情况，会导致后续应用启动失败（结合上述的不加入任何import的条件），这取决于两个属性

spring.cloud.bootstrap.enabled || spring.config.use-legacy-processing 亦或者添加依赖 spring-cloud-starter-bootstrap 这个需要考虑么

另外再确认下最终期望结果，在无任何import配置下，NacosConfigManager能获取当前的全部环境变量是么

可以把这个交给我么

Dec 05 '25 10:12 chiangzeon

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

因为如果没有配置任何 import 条目，NacosConfigDataLocationResolver 不会执行（注意 isResolvable 方法做了 hasPrefix 判断）。而 NacosConfigManager 能正确注册，取决于 NacosConfigDataLocationResolver.registerConfigManager 方法。因为 NacosConfigDataLocationResolver 不会执行，导致自动配置类中默认初始化的 NacosConfigManager 是一个参数不全的 NacosConfigProperties 对象。它里面不会包含可靠的配置文件、启动参数方式传入的所有参数。所以应用程序中注入的这个 NacosConfigManager 就是一个属性可能就是 java 对象默认值的对象（写一个 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容，不做任何 import 的情况下应该能直接发现问题）。然后我认为，在 NacosConfigManager 的 afterPropertiesSet 方法中获取 environment 中的配置，初始化 NacosConfigManager 的 nacosConfigProperties 属性，也符合 spring 对 afterPropertiesSet 设计的意义。我认为这是一种比较可靠准确解决问题的方式。因为执行 afterPropertiesSet 时，environment 此时是完整包含了所有配置的内容。比如 application.yml 中、通过启动参数传入的、电脑环境变量中配置的，此时 environment 中的 nacos 配置是比较可靠的。

但实际运行中，由于NacosConfigDataMissingEnvironmentPostProcessor派生自ConfigDataMissingEnvironmentPostProcessor，shouldProcessEnvironment返回true的情况，会导致后续应用启动失败（结合上述的不加入任何import的条件），这取决于两个属性 spring.cloud.bootstrap.enabled || spring.config.use-legacy-processing 亦或者添加依赖 spring-cloud-starter-bootstrap 这个需要考虑么另外再确认下最终期望结果，在无任何import配置下，NacosConfigManager能获取当前的全部环境变量是么

可以把这个交给我么

我提交过了PR https://github.com/alibaba/spring-cloud-alibaba/pull/4148 。

Dec 06 '25 00:12 xzxiaoshan

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置

你好，“通过在 NacosConfigManager 的 bean 初始化完成之前，从整个 env 中重新刷新配置”这段我不是很理解，能解释下什么意思么

因为如果没有配置任何 import 条目，NacosConfigDataLocationResolver 不会执行（注意 isResolvable 方法做了 hasPrefix 判断）。而 NacosConfigManager 能正确注册，取决于 NacosConfigDataLocationResolver.registerConfigManager 方法。因为 NacosConfigDataLocationResolver 不会执行，导致自动配置类中默认初始化的 NacosConfigManager 是一个参数不全的 NacosConfigProperties 对象。它里面不会包含可靠的配置文件、启动参数方式传入的所有参数。所以应用程序中注入的这个 NacosConfigManager 就是一个属性可能就是 java 对象默认值的对象（写一个 CommandLineRunner 中注入 NacosConfigManager ，debug 查看该对象实例的属性内容，不做任何 import 的情况下应该能直接发现问题）。然后我认为，在 NacosConfigManager 的 afterPropertiesSet 方法中获取 environment 中的配置，初始化 NacosConfigManager 的 nacosConfigProperties 属性，也符合 spring 对 afterPropertiesSet 设计的意义。我认为这是一种比较可靠准确解决问题的方式。因为执行 afterPropertiesSet 时，environment 此时是完整包含了所有配置的内容。比如 application.yml 中、通过启动参数传入的、电脑环境变量中配置的，此时 environment 中的 nacos 配置是比较可靠的。

但实际运行中，由于NacosConfigDataMissingEnvironmentPostProcessor派生自ConfigDataMissingEnvironmentPostProcessor，shouldProcessEnvironment返回true的情况，会导致后续应用启动失败（结合上述的不加入任何import的条件），这取决于两个属性

spring.cloud.bootstrap.enabled || spring.config.use-legacy-processing 亦或者添加依赖 spring-cloud-starter-bootstrap 这个需要考虑么

另外再确认下最终期望结果，在无任何import配置下，NacosConfigManager能获取当前的全部环境变量是么

决定是否启动 config 配置中心的是 enable，只要 config 开启了，并且在项目中能成功注入 NacosConfigManager 对象的情况下，NacosConfigManager 就应该是准确可用的对象，而不应该因为没有写任何 import，它就变成了一个配置不正确的对象了。

我提交了 PR，你可以 review 一下。 https://github.com/alibaba/spring-cloud-alibaba/pull/4148

Dec 06 '25 00:12 xzxiaoshan

你好，这个问题我专门和 Nacos 社区的同学进行了确认。很遗憾，目前的结论是：在 SpringBoot 场景下，未配置 spring.config.import 的情况下，不自动初始化 NacosConfigManager 对象是符合预期的。换句话说，只要你是 SpringBoot 应用，配置 spring.config.import 的情况下，才会正确地加载配置，目前就是如此设计的。

你可以看到 NacosConfigDataLocationResolver 是对 SpringBoot 的 ConfigDataLocationResolver 标准的实现，符合 SpringBoot 的操作逻辑和使用规范。

即便你需要编程式地使用 Nacos config，简单起见，你也应该配置 spring.config.import，这是正确且标准的用法。如果你不想配置 spring.config.import，那么你就需要手工通过一些 SpringBoot 或 Spring 扩展点来实现 Nacos config 的初始化加载，但这样的做法并不值得推荐。

很高兴你对 SpringCloud Alibaba 源码有深入的见解，并且提出如此细致翔实的 issue（这很难得~ 👍 👍 👍 ），也欢迎你帮忙解决社区其他 issue!

Dec 08 '25 03:12 uuuyuqi

你好，这个问题我专门和 Nacos 社区的同学进行了确认。很遗憾，目前的结论是：在 SpringBoot 场景下，未配置 spring.config.import 的情况下，不自动初始化 NacosConfigManager 对象是符合预期的。换句话说，只要你是 SpringBoot 应用，配置 spring.config.import 的情况下，才会正确地加载配置，目前就是如此设计的。

你可以看到 NacosConfigDataLocationResolver 是对 SpringBoot 的 ConfigDataLocationResolver 标准的实现，符合 SpringBoot 的操作逻辑和使用规范。

即便你需要编程式地使用 Nacos config，简单起见，你也应该配置 spring.config.import，这是正确且标准的用法。如果你不想配置 spring.config.import，那么你就需要手工通过一些 SpringBoot 或 Spring 扩展点来实现 Nacos config 的初始化加载，但这样的做法并不值得推荐。

很高兴你对 SpringCloud Alibaba 源码有深入的见解，并且提出如此细致翔实的 issue（这很难得~ 👍 👍 👍 ），也欢迎你帮忙解决社区其他 issue!

你好，我想你们可能没有真正的debug验证。现在并不是如你所说没有import就不会有nacosconfigmanager对象。就算没有配置任何import目前也是能注入bean对象的。你们要么如你所说不import就不初始化它那也没有问题。现在实际情况是初始化了一个错误的。我的修改并没有增加额外的初始化，pr的代码仅仅是确保属性的准确性，所以它应该属于代码完善或优化而不属于改变规则。

我本身也是在nacos的社区群里，只不过不在这个cloud群里。希望你们能理解我的意思，或者有微信等其他方式进一步讨论。

Dec 08 '25 03:12 xzxiaoshan

如果库如反馈所述不import就完全不实例nacosconfigmanager，需要自定义的开发场景自然可以自己初始化。关键是没有配置import你们搞了一个错误的对象占在spring容器中，这本身不就是问题吗？自相矛盾啊。希望你们能充分理解我的意思，也希望你们最好充分debug验证。盼复，谢谢

Dec 08 '25 04:12 xzxiaoshan

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

Dec 08 '25 04:12 xzxiaoshan

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

我理解下来的意思，nacosconfigmanager确实存在于spring context中，但它处于一个中间态，有这个实例，但变量是未加载的，本次pr的目的，其实是希望处于一个强一致性。情况1、如未配置import，则context中不存在NacosConfigManager 情况2、如未配置import，则按照已知内容，如server-addr等其他属性去加载，保证NacosConfigManager对象的可用性本次pr的目的是情况2。不知是否看法一致

Dec 08 '25 05:12 chiangzeon

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

我理解下来的意思，nacosconfigmanager确实存在于spring context中，但它处于一个中间态，有这个实例，但变量是未加载的，本次pr的目的，其实是希望处于一个强一致性。情况1、如未配置import，则context中不存在NacosConfigManager 情况2、如未配置import，则按照已知内容，如server-addr等其他属性去加载，保证NacosConfigManager对象的可用性本次pr的目的是情况2。不知是否看法一致

正是，完全是你理解的一样。

所以库要么符合1 即不该存在这个实例。要么符合2 即存在了就应该是正确的。PR解决了2的错误问题并没有改变设计初衷。

Dec 08 '25 06:12 xzxiaoshan

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

我理解下来的意思，nacosconfigmanager确实存在于spring context中，但它处于一个中间态，有这个实例，但变量是未加载的，本次pr的目的，其实是希望处于一个强一致性。情况1、如未配置import，则context中不存在NacosConfigManager 情况2、如未配置import，则按照已知内容，如server-addr等其他属性去加载，保证NacosConfigManager对象的可用性本次pr的目的是情况2。不知是否看法一致

正是，完全是你理解的一样。

所以库要么符合1 即不该存在这个实例。要么符合2 即存在了就应该是正确的。PR解决了2的错误问题并没有改变设计初衷。

但是有个点尚未提及，就是spring-cloud-starter-bootstrap依赖或spring.cloud.bootstrap.enabled、spring.config.use-legacy-processing属性，因为按现有流程，如果缺失该依赖或属性设置为true，在缺少import配置时，应用将无法启动，代码块见org.springframework.cloud.commons.ConfigDataMissingEnvironmentPostProcessor#postProcessEnvironment @uuuyuqi

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

Dec 08 '25 10:12 chiangzeon

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

我理解下来的意思，nacosconfigmanager确实存在于spring context中，但它处于一个中间态，有这个实例，但变量是未加载的，本次pr的目的，其实是希望处于一个强一致性。情况1、如未配置import，则context中不存在NacosConfigManager 情况2、如未配置import，则按照已知内容，如server-addr等其他属性去加载，保证NacosConfigManager对象的可用性本次pr的目的是情况2。不知是否看法一致

正是，完全是你理解的一样。所以库要么符合1 即不该存在这个实例。要么符合2 即存在了就应该是正确的。PR解决了2的错误问题并没有改变设计初衷。

但是有个点尚未提及，就是spring-cloud-starter-bootstrap依赖或spring.cloud.bootstrap.enabled、spring.config.use-legacy-processing属性，因为按现有流程，如果缺失该依赖或属性设置为true，在缺少import配置时，应用将无法启动，代码块见org.springframework.cloud.commons.ConfigDataMissingEnvironmentPostProcessor#postProcessEnvironment @uuuyuqi
org.springframework.cloud spring-cloud-starter-bootstrap

NacosConfigDataMissingEnvironmentPostProcessor 这个类中nacos给出了可以关闭检查的提示。

		String action = "Add a spring.config.import=nacos: property to your configuration.\n"
				+ "\tIf configuration is not required add spring.config.import=optional:nacos: instead.\n"
				+ "\tTo disable this check, set spring.cloud.nacos.config.import-check.enabled=false.";

Dec 08 '25 10:12 xzxiaoshan

@chiangzeon 这位参与讨论的开发者，你怎么看呢？

我理解下来的意思，nacosconfigmanager确实存在于spring context中，但它处于一个中间态，有这个实例，但变量是未加载的，本次pr的目的，其实是希望处于一个强一致性。情况1、如未配置import，则context中不存在NacosConfigManager 情况2、如未配置import，则按照已知内容，如server-addr等其他属性去加载，保证NacosConfigManager对象的可用性本次pr的目的是情况2。不知是否看法一致

正是，完全是你理解的一样。所以库要么符合1 即不该存在这个实例。要么符合2 即存在了就应该是正确的。PR解决了2的错误问题并没有改变设计初衷。

但是有个点尚未提及，就是spring-cloud-starter-bootstrap依赖或spring.cloud.bootstrap.enabled、spring.config.use-legacy-processing属性，因为按现有流程，如果缺失该依赖或属性设置为true，在缺少import配置时，应用将无法启动，代码块见org.springframework.cloud.commons.ConfigDataMissingEnvironmentPostProcessor#postProcessEnvironment @uuuyuqi
org.springframework.cloud
spring-cloud-starter-bootstrap
NacosConfigDataMissingEnvironmentPostProcessor 这个类中nacos给出了可以关闭检查的提示。
		String action = "Add a spring.config.import=nacos: property to your configuration.\n"
				+ "\tIf configuration is not required add spring.config.import=optional:nacos: instead.\n"
				+ "\tTo disable this check, set spring.cloud.nacos.config.import-check.enabled=false.";

因为spi会加载其他实现相同interface的class，所以即便检查未启用，会走到标准spring的实现，那块存在有无spring.config.import的断言

Dec 08 '25 10:12 chiangzeon

你好，我想你们可能没有真正的debug验证。现在并不是如你所说没有import就不会有nacosconfigmanager对象。就算没有配置任何import目前也是能注入bean对象的。你们要么如你所说不import就不初始化它那也没有问题。现在实际情况是初始化了一个错误的。我的修改并没有增加额外的初始化，pr的代码仅仅是确保属性的准确性，所以它应该属于代码完善或优化而不属于改变规则。

我本身也是在nacos的社区群里，只不过不在这个cloud群里。希望你们能理解我的意思，或者有微信等其他方式进一步讨论。

抱歉，可能我前面没有说明清楚，我想表达的是：在没有配置 spring.config.import 的时候，NacosConfigManager 这个 bean 拿不到 config 数据是符合预期的，即便此时 NacosConfigManager 这个 bean 存在于 Spring Context 中且可以被编程方式使用。至少设计初衷上，spring.config.import 一定是必需的。（值得一提的是，SCA 对 SpringCloud Bootstrap 相关的适配内容，会在后续版本中删除，目前不会再去主动维护，也不推荐继续使用该功能）

我和 Nacos 社区同学（cc @shiyiyue1102 ）也聊过，spring.config.import 是 Nacos 社区对外透出的最佳实践。如果没有配置 spring.config.import，那应该阻碍 NacosConfigManager 这个 bean 的自动配置。欢迎你提交 PR 来增加该特性~ 😁

btw 如果你的环境中使用了 SpringCloud Bootstrap，正如 @chiangzeon 上文提到的，可能不会对 spring.config.import 进行校验，否则在引入 SCA nacos config 后，检测到没有 import nacos 时会阻塞你的应用启动，并报错 "Add a spring.config.import=nacos: property to your configuration." 字样。

Dec 08 '25 13:12 uuuyuqi

我这边最近没有时间处理这个了，我只按照上文的第2点的一致性问题解决了第2点的一致性问题。

现在结论选择第1点来解决一致性问题，如果 @chiangzeon 方便的话可以处理，或者由其他同学处理。

Dec 09 '25 00:12 xzxiaoshan

我这边最近没有时间处理这个了，我只按照上文的第2点的一致性问题解决了第2点的一致性问题。

现在结论选择第1点来解决一致性问题，如果 @chiangzeon 方便的话可以处理，或者由其他同学处理。

好的，我来看下

Dec 09 '25 00:12 chiangzeon

你好，我想你们可能没有真正的debug验证。现在并不是如你所说没有import就不会有nacosconfigmanager对象。就算没有配置任何import目前也是能注入bean对象的。你们要么如你所说不import就不初始化它那也没有问题。现在实际情况是初始化了一个错误的。我的修改并没有增加额外的初始化，pr的代码仅仅是确保属性的准确性，所以它应该属于代码完善或优化而不属于改变规则。我本身也是在nacos的社区群里，只不过不在这个cloud群里。希望你们能理解我的意思，或者有微信等其他方式进一步讨论。

抱歉，可能我前面没有说明清楚，我想表达的是：在没有配置 spring.config.import 的时候，NacosConfigManager 这个 bean 拿不到 config 数据是符合预期的，即便此时 NacosConfigManager 这个 bean 存在于 Spring Context 中且可以被编程方式使用。至少设计初衷上，spring.config.import 一定是必需的。（值得一提的是，SCA 对 SpringCloud Bootstrap 相关的适配内容，会在后续版本中删除，目前不会再去主动维护，也不推荐继续使用该功能）

我和 Nacos 社区同学（cc @shiyiyue1102 ）也聊过，spring.config.import 是 Nacos 社区对外透出的最佳实践。如果没有配置 spring.config.import，那应该阻碍 NacosConfigManager 这个 bean 的自动配置。欢迎你提交 PR 来增加该特性~ 😁

btw 如果你的环境中使用了 SpringCloud Bootstrap，正如 @chiangzeon 上文提到的，可能不会对 spring.config.import 进行校验，否则在引入 SCA nacos config 后，检测到没有 import nacos 时会阻塞你的应用启动，并报错 "Add a spring.config.import=nacos: property to your configuration." 字样。

你好，请查看 https://github.com/alibaba/spring-cloud-alibaba/pull/4156

Dec 09 '25 05:12 chiangzeon

3.5.8 2025.0.0 3.1.7 2025.0.0.0 21 为啥会配置报红，不读配置，但是服务可以注册上去

Dec 15 '25 11:12 ZYX2018

3.5.8 2025.0.0 3.1.7 2025.0.0.0 21 为啥会配置报红，不读配置，但是服务可以注册上去

SCA 2023.0.1.3 开始，已经不推荐使用 Bootstrap 模式。最好的方式就是将所有的 bootstrap.yml 修改为 application.yml。见3998#issuecomment-3003694073

Dec 17 '25 03:12 herodotus-ecosystem