Profile命名的环境陷阱

用 profile 控制哪些 bean 该被加载时，一个常见错误是直接照搬部署环境的名字（dev/test/prod）来命名 profile。这样做会把应用和部署环境死死绑在一起：哪天多出一个 staging 环境，要么牵强地在 staging 上激活 prod 这个名不副实的 profile，要么改代码新增一个 staging profile——后者意味着每加一个环境就要重新构建一次应用，直接违反了”同一份构建部署到任意环境”的不可变性。正确做法是按 profile 提供的功能而不是它会在哪里被启用来命名——比如用 testdata 这个 profile 名表示”要不要在启动时灌入测试数据”，这个开关和它到底在哪个环境被打开完全无关。发散：这条陷阱的通用形式是——凡是给开关命名时用了”在哪用”而不是”做什么用”，都埋了同样的雷，[[15-Factor方法论的定位]]里反复强调的可移植性，往往就是被这种命名习惯不知不觉破坏掉的。