应避免在模型中调用env()，因其导致配置不可预测、无法响应运行时环境切换、破坏单元测试；正确做法是提前注入环境值或使用config()替代。
在模型里调用 env() 会导致配置不可预测
ThinkPHP 的配置加载是一次性行为，发生在应用初始化阶段（App::initialize() 之前）。模型类通常在请求生命周期中后期才被实例化，此时 env() 虽然能返回值，但已脱离配置合并上下文。更关键的是：如果模型被用于命令行、队列、Swoole 长连接等非 HTTP 场景，env() 可能返回 null 或旧缓存值，而你完全感知不到。
env() 在模型里无法响应运行时环境切换
ThinkPHP 不支持运行时动态切换 APP_ENV 或重载 .env 文件。一旦应用启动，所有 env() 调用都基于首次加载的结果。若你在模型里写：env('DB_PREFIX', 'pre_')，它不会因当前请求来自测试域名或 CLI 参数而改变——哪怕你手动设置了 $_ENV['APP_ENV'] = 'test'，也不会触发重新解析。
模型里硬编码 env() 会让单元测试和 Mock 失效
模型方法若直接依赖 env('API_TIMEOUT')，就无法通过传参或依赖注入方式覆盖该值。你不能在测试中临时改环境变量来验证超时逻辑，因为：
-
putenv()和$_ENV修改对已加载的env()缓存无效 -
think\Env内部使用静态属性缓存结果，unset()无法清除 - Mock
env()函数需用 PHPUnit 的functionMock，但会污染全局作用域
真正安全的替代方式是把 env 值“提前注入”到模型
不要让模型自己去读环境变量。正确做法是在服务提供者、中间件或控制器中读取一次，再以构造参数、setter 或上下文方式传入模型：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/provider/AppServiceProvider.php中绑定带环境值的模型实例 - 用
config('database.prefix')替代env('DB_PREFIX')—— 因为 config 已完成环境变量解析且可被缓存、覆盖、测试 - 对高度敏感的值（如密钥），改用
think\facade\Cache+ 密钥管理服务，避免模型直连env()
最常被忽略的一点：模型里出现 env() 往往意味着配置职责错位——环境变量是启动时的输入，不是业务逻辑的参数。把它留在配置层，比在模型里反复判断要干净得多。
