Nacos 配置已拉取却报 does not exist，先查重复 YAML 键

启动日志先显示 [Nacos Config] Load config ... success，接着又报配置 does not exist 并建议加 optional:。这种顺序下，不要先认定 Nacos 没有该配置：内容可能已经拉到，失败发生在随后解析 YAML 时。

在 Spring Cloud Alibaba 2025.1.0.0 的 NacosConfigDataLoader 中，拉取与解析共用异常处理路径。非 optional 导入遇到解析异常，也可能被包装成 ConfigDataResourceNotFoundException；真正原因要从 Error getting properties from nacos 后的完整堆栈和 cause 中判断。

找到 DuplicateKeyException 对应的两处配置

核对当前应用实际使用的 Nacos namespace、group、dataId 和导入格式，再查看它取得的那份内容。日志里的成功信息在调用解析器之前产生，不能表示属性已经绑定并被业务使用。

例如，同一个 YAML 文档重复定义顶层键：

single:
  oss:
    path-style-access: true
single:
  oss:
    path-style-access: true

解析器拒绝重复键时，堆栈中会出现 DuplicateKeyException 及对应位置。两处值相同，也不意味着重复定义合法。按业务含义合并到同一个 single 下，保留其中唯一的 oss.path-style-access；不能随手删除一整段而丢掉它下面其他不同属性。

要区分同一文档中的重复键、不同 YAML 文档或 profile 的合法覆盖，以及多个导入来源的优先级。这里只修复已被解析器指出的重复定义，不把所有同名配置都当成错误。

optional 可能让错误配置被跳过

在上述正式版本的处理路径中，加了 optional: 后，异常会被记录，加载器随后返回空结果。应用可能继续启动，再使用其他来源或默认值；也可能在更晚阶段因必要配置缺失而失败。

因此，启动成功不能证明这份配置恢复正常。依赖它提供数据库地址、认证开关等必要属性时，不应通过添加 optional 隐藏解析失败。先修正 YAML，再确认应用取得预期属性。

如果没有解析异常，而确实是 dataId 不存在、权限或连接失败，应沿对应 cause 检查。Load config ... success 的另一时刻记录，也不能证明当前失败请求成功，日志必须对应同一个加载过程。

区分正式版本与分支上的错误提示改进

2025.1.x 分支已有针对 DuplicateKeyException 的处理改动，把它报告为配置解析异常，并避免 optional 吞掉这类错误。分支合并不能直接当成正在运行的正式依赖已修复；也不能推断所有解析异常都被同样处理。

检查构建实际解析出的 Spring Cloud Alibaba 依赖与最终运行包，而不是只看项目声明的版本。升级时按兼容的 Spring Boot、Spring Cloud 和 Alibaba 版本组合进行；更清楚的异常提示仍不会自动修正重复 YAML。

发布修正前保留可回退的配置

保存原内容与发布记录，先在隔离环境用相同解析条件检查修正后的 YAML，再按当前配置发布流程更新。诊断不要输出整份可能包含口令的配置。

验证原来失败的应用能完整加载该 dataId、没有新的解析异常，并核对业务读取的关键属性值。若应用采用动态刷新，还要验证实际刷新路径；启动导入通过与运行期刷新成功是不同结果。

回退时恢复经过确认的上一份有效配置及其发布方式。原本包含重复键的内容只能保留作诊断证据，不能把“回到有错误的版本”当成恢复服务的保证。