Env类仅为环境变量读取门面，不解析.env文件；真正解析由vlucas/phpdotenv等库完成，且必须在Env调用前通过putenv()或$_ENV注入变量，否则Env::get()将返回null或默认值。
Env 类不是独立加载器，它只是环境变量的读取门面
ThinkPHP 的 Env 类（如 think\facade\Env 或 think\Env）本身不负责解析 .env 文件，也不管理加载时机。它只是一个静态代理，底层实际调用的是 PHP 原生的 getenv()、$_ENV 或 $_SERVER —— 换句话说，它只读“已存在”的环境变量，不管这些变量是谁塞进去的。
常见误解是以为 Env::get('DB_HOST') 会自动去读 .env 文件。不会。如果 DB_HOST 没被提前注入到进程环境里，它就返回 null 或默认值（取决于你是否传了第二个参数）。
-
Env::get('KEY')等价于getenv('KEY') ?: $_ENV['KEY'] ?? $_SERVER['KEY'] ?? null - 它不处理大小写转换：若
.env写的是db_host=127.0.0.1，Env::get('DB_HOST')一定返回null，因为变量名必须全大写+下划线 - 它不解析引号或转义：如果
DB_PWD='pass@123!'已被正确加载进环境，Env::get('DB_PWD')就直接返回pass@123!；但如果加载失败（比如编码带 BOM），它照样安静地返回null
真正干活的是 Dotenv 或手动 parse_ini_file，不是 Env 类
在 ThinkPHP 6.x/8.x 中，.env 文件的解析工作由外部库 vlucas/phpdotenv 完成；而 TP5 则用原生 parse_ini_file()（但该函数并不兼容标准 .env 格式，仅因 TP5 自定义了节名逻辑才勉强可用）。
关键点在于：这些解析动作必须在 Env 被调用之前完成，且结果要通过 putenv() 或 $_ENV 注入运行时环境。
立即学习“PHP免费学习笔记（深入）”；
- TP6 推荐方式：在
public/index.php中显式调用Dotenv\Dotenv::createImmutable(__DIR__.'/..')->load() - TP5 方式：入口中用
parse_ini_file(ROOT_PATH .'.env', true)+ 循环putenv()（注意它要求.env有[default]这样的节名） - TP8 多环境场景：需先设好系统级
APP_ENV，再手动加载对应.env.dev等文件，Env类仍然只负责读，不参与选择逻辑
Env::get() 的默认值参数不是摆设，而是防崩刚需
很多线上问题源于没给 Env::get() 提供第二参数。一旦环境变量缺失，返回 null 可能导致数据库连接失败、Redis 初始化报错，甚至配置数组键缺失引发 Notice。
- 数据库主机不能写成
'hostname' => Env::get('DB_HOST')，必须写成'hostname' => Env::get('DB_HOST', '127.0.0.1') - 密码字段尤其危险：
Env::get('DB_PWD')返回null会被当成空字符串连接，但有些驱动会把它当作字面量null字符串尝试认证 - 前缀、端口等字段推荐用空字符串或整数默认值，而不是
null：Env::get('DB_PORT', 3306)比Env::get('DB_PORT')更可控
调试时别只看 Env::get()，要分层验证来源
当 Env::get('APP_ENV') 不符合预期，不能只查 .env 文件内容。必须逐层确认变量到底来自哪一层：
- 执行
var_dump(getenv('APP_ENV'))：这是最原始的系统环境变量值 - 执行
var_dump($_ENV['APP_ENV'] ?? null)：确认是否被putenv()或Dotenv写入 - 执行
var_dump(Env::get('APP_ENV'))：最终 facade 封装后的结果 - 如果三者不一致，说明中间某步被覆盖或跳过 —— 最常见的是 Nginx 的
fastcgi_param APP_ENV prod直接压过了.env
真正容易被忽略的是：.env 文件只要有一个字符编码错误（比如 Windows 记事本保存的 UTF-8 with BOM），Dotenv 就会静默失败，而 Env 类对此毫无感知，只会安静地返回默认值或 null。这种错误不会抛异常，也不会打日志，只能靠 file -i .env 或编辑器编码检测来定位。
