Env::get()仅用于运行时读取，不能替代配置加载；env()函数必须在config/*.php文件中调用，确保配置在App::initialize()前完成初始化，否则.env修改无效。
Env::get() 在控制器里能用，但不该用来替代配置加载
不能靠控制器里调用 Env::get('DB_HOST') 来“验证环境变量是否生效”——这只会掩盖配置没真正加载的问题。ThinkPHP 的配置系统是单次初始化的，所有 env() 调用必须在 config/*.php 文件中完成，且仅在 App::initialize() 阶段执行。控制器里调用只是读取已存在的 PHP 环境变量（$_ENV 或 getenv()），和框架配置无关。
- 常见错误：改完
.env后，在控制器里写dump(Env::get('APP_DEBUG'))发现输出true，就以为数据库配置也跟着变了——其实config/database.php里的'hostname' => env('DB_HOST', '127.0.0.1')这一行根本没被重新执行 - 真实场景：CI/CD 流水线跑单元测试时，控制器里
Env::get('REDIS_HOST')返回正确值，但缓存连接仍失败，因为config/cache.php没用env()替换对应字段 - 性能影响：每次请求都调用
Env::get()会触发底层getenv()查表，虽开销小，但若高频使用（如循环内），不如提前在配置里解析好
哪些情况真需要在控制器里读 Env
只有两类合理用途：一是调试排查，二是动态行为分支（比如灰度开关）。但必须清楚它不参与框架配置生命周期。
- 调试用法：在控制器开头加
dump(getenv('APP_ENV'), \think\Env::get('APP_ENV'))，对比两者是否一致，可快速判断是系统级变量覆盖了.env，还是think-env加载失败 - 灰度逻辑：比如
if (\think\Env::get('FEATURE_PAY_V2', 'off') === 'on') { ... }，这类开关应独立于数据库、缓存等主配置，避免耦合 - 绝对不要做：把
Env::get('DB_NAME')直接拼进Db::connect()参数里——这绕过了连接池管理，且无法享受配置缓存优化
CLI 模式下控制器读 Env 更容易失效
命令行运行 php think make:command TestCommand 时，控制器类可能根本不会被加载，而 Env::get() 在 CLI 下默认不自动加载 .env，导致返回 null 或空字符串。
- 根本原因：ThinkPHP 8 默认只在 HTTP 生命周期中由
think-env自动加载.env；CLI 入口（think文件）需手动插入\Dotenv\Dotenv::createImmutable(__DIR__)->safeLoad() - 验证方法：在命令类
handle()中执行var_dump($_ENV['DB_HOST'] ?? 'not set')，若为'not set'，说明.env根本没进 PHP 环境，此时控制器里任何Env::get()都无效 - Windows 用户特别注意：
set APP_ENV=dev && php think run设置的变量仅当前命令有效，且若.env是记事本保存的 UTF-8 with BOM，safeLoad()会静默跳过整文件
env() 和 Env::get() 的行为差异必须分清
env() 是函数，用于配置文件；Env::get() 是门面类方法，用于运行时读取。两者底层都依赖 getenv()，但加载时机和作用域完全不同。
立即学习“PHP免费学习笔记（深入）”；
-
env('DB_PORT', 3306)必须出现在config/database.php等配置文件中，框架启动时解析并固化进配置数组 -
\think\Env::get('DB_PORT')是运行时调用，每次执行都查$_ENV或getenv()，若该变量未被Dotenv::load()注入，就永远拿不到值 - 一个典型坑：
env('APP_ENV', 'production')在配置文件里写，和\think\Env::get('APP_ENV')在控制器里读，返回值可能不同——前者读的是.env解析后的结果，后者读的是系统APP_ENV变量（如 Linux 下export APP_ENV=test）
实际项目里最常被忽略的一点：.env 文件编码为 UTF-8 with BOM 时，Dotenv::safeLoad() 不报错也不警告，直接跳过整文件，所有 env() 和 Env::get() 都返回默认值或 null。 这种静默失效比报错更难排查。
