Erlang/OTP中应用环境变量设置的陷阱与解决方案

背景介绍

在Erlang/OTP开发过程中，应用环境变量的配置是一个常见操作。开发者通常使用application:set_env/3函数来动态设置应用的环境变量，这在测试场景中尤其有用。然而，当与CT测试框架结合使用时，特别是在配置了sys_config文件的情况下，会出现一个不太直观的行为陷阱。

问题现象

当我们在CT测试套件的init_per_suite回调中使用application:set_env/3设置环境变量后，表面上函数返回ok表示操作成功，变量也确实被设置。然而，一旦后续调用application:ensure_all_started/1启动应用，之前设置的环境变量会被sys_config文件中的配置覆盖，导致测试失败。

问题重现

1. 创建一个简单的Erlang库项目
2. 在rebar.config中配置CT测试使用sys_config文件
3. 在测试套件中先设置环境变量，再启动应用
4. 测试断言会失败，因为环境变量被重置

根本原因

这个问题的核心在于Erlang应用启动时的环境变量加载机制。当应用启动时，它会按照以下顺序加载环境变量：

1. 首先加载sys_config文件中定义的配置
2. 然后加载代码中通过application:set_env设置的变量
3. 但如果没有指定persistent选项，这些设置不会被保留到应用启动阶段

解决方案

正确的做法是使用application:set_env/4并设置persistent选项为true：

ok = application:set_env(ct_err, env_var, x, [{persistent, true}]),

这样设置的环境变量会在应用启动过程中保持，不会被sys_config文件中的配置覆盖。

深入理解

Erlang应用环境变量的持久性有三个级别：

1. 临时设置：默认的application:set_env/3调用，只在当前运行时有效
2. 持久设置：使用persistent选项，会跨应用重启保持
3. 配置文件设置：通过sys_config或.app文件定义，具有最高优先级

最佳实践

1. 在测试中需要覆盖配置时，总是使用persistent选项
2. 考虑在测试清理阶段恢复原始配置
3. 对于关键配置，可以在测试中验证环境变量是否按预期设置
4. 理解不同配置源的优先级顺序

总结

这个案例展示了Erlang/OTP中应用环境配置的一个微妙之处。理解环境变量的生命周期和持久性机制对于编写可靠的测试代码至关重要。通过正确使用persistent选项，开发者可以确保测试中的配置覆盖按预期工作，避免因配置问题导致的测试失败。