为何Spring需spring.profiles.default而非仅用spring.profiles.active？

一、为什么Spring要设计spring.profiles.default？ #

它的核心作用是提供「无显式激活Profile时的自动兜底逻辑」，和spring.profiles.active的定位完全不同：

• spring.profiles.active用来显式指定要激活的环境/配置集，代表用户的主动选择；
• spring.profiles.default则是当用户没有做出任何主动选择（即未设置spring.profiles.active）时，Spring自动启用的默认配置集，本质是一种安全的 fallback 机制，避免因未配置环境导致应用无法启动或使用错误配置。

就像你提供的示例代码中，DefaultDataConfig用@Profile("default")标记，当开发者忘了设置spring.profiles.active时，会自动创建嵌入式数据库的DataSource；一旦显式激活了prod或dev这类Profile，这个默认配置就会自动失效，不会被误用到生产环境。

二、直接用spring.profiles.active能否达成相同效果？ #

理论上可以通过给spring.profiles.active设置默认值模拟部分效果，但会带来逻辑混淆，且无法实现Spring默认Profile的核心特性：

• 如果把spring.profiles.active的默认值设为default，你无法区分「用户完全没配置active」和「用户主动选择了default环境」这两种情况——而Spring的默认Profile逻辑中，只要有任意active Profile被激活（哪怕是default），原来的“无激活时兜底”的自动逻辑就会被覆盖，两者语义完全不同。
• 更关键的是，Spring默认Profile的核心特性是**“只要有任意active Profile激活，默认配置自动失效”**，这个逻辑用spring.profiles.active无法直接实现，除非你自己编写额外的条件判断逻辑，而Spring已经通过spring.profiles.default封装好了这个场景。

三、何时必须使用spring.profiles.default而非spring.profiles.active？ #

有三类场景必须用spring.profiles.default才能实现预期效果：

1. 需要区分「无主动选择」和「主动选择默认环境」的场景
   比如你希望：当用户完全没配置环境时，用最简化的兜底配置（如嵌入式数据库）；当用户主动指定active=default时，也用这个配置；但当用户指定active=prod时，自动切换到生产配置。这种语义上的区分，只有spring.profiles.default能实现——因为只要有active Profile存在，默认的兜底逻辑就会自动禁用。
2. 需要默认配置自动失效的场景
   比如你的应用有dev、test、prod三种环境配置，每个环境都有自己的DataSource Bean，同时希望当用户没指定任何环境时，用一个默认的嵌入式DataSource。此时用@Profile("default")标记默认Bean，Spring会自动在无active Profile时启用它，一旦激活任何其他Profile，默认Bean就自动失效，不需要手动写条件判断来排除默认配置。
3. 模块化配置的兜底场景
   当应用由多个模块组成，每个模块都提供自己的默认配置（如默认的缓存实现、默认的消息队列配置），同时允许用户通过激活特定Profile来覆盖模块的默认配置。此时用spring.profiles.default可以让所有模块的默认配置在无active Profile时自动生效，一旦用户激活某个Profile，对应模块的特定配置就会覆盖默认配置，无需在每个模块中编写重复的条件逻辑。

内容的提问来源于stack exchange，提问作者Manuel Jordan