getenv()更可靠，因$_ENV默认为空且依赖php.ini中variables_order含E；phpdotenv仅注入环境变量到getenv()可见区，不自动填充$_ENV，加载时机、SAPI差异及外部环境隔离才是关键。
phpdotenv 是 PHP 项目中加载 .env 文件的常用库，但**它本身不解决环境变量管理问题，只负责“读取并注入”**。真正的问题往往出在加载时机、作用域、覆盖逻辑或部署上下文上。直接用 composer require vlucas/phpdotenv 装完就以为万事大吉，反而容易埋坑。
为什么 phpdotenv 加载后 getenv() 还是空？
常见现象：.env 文件内容正确，Dotenv::createImmutable(__DIR__)->load(); 也执行了，但 getenv('DB_HOST') 返回 false 或空字符串。
-
getenv()默认不返回被覆盖的变量（PHP 7.1+ 默认variables_order不含E）——需确保php.ini中variables_order = "EGPCS"，或改用$_ENV -
Dotenv::createImmutable()不会自动写入$_ENV，只写入$_SERVER和getenv()可见区；若需$_ENV，得显式调用->safeLoad()或启用putenv()后再$_ENV = getenv(); - 框架（如 Laravel）通常在 bootstrap 阶段提前加载了
.env，你手动再 load 一次可能被忽略或覆盖
phpdotenv 在 CLI 和 Web 请求中行为不一致？
根本原因是 SAPI 环境差异：CLI 进程每次启动都是干净的，而 Web 服务器（如 Apache/FPM）进程常驻，putenv() 设置的变量可能残留或被复用。
- CLI 下多次运行脚本，
putenv()变量不会自动清理，下次运行可能误用上一次的值 - FPM 下 worker 进程复用，若某次请求修改了
putenv('APP_ENV=prod')，后续请求可能继承该值（除非重置） - 推荐做法：始终使用
Dotenv::createUnsafeImmutable()+ 显式$_ENV = array_merge($_ENV, $dotenv->load());，避免依赖putenv()
和 Docker / Nginx / crontab 配合时变量总丢？
phpdotenv 是 PHP 层的解决方案，它无法干预外部环境是否提供基础变量（比如 PATH、HOME），更不解决系统级变量隔离问题。
- Docker 容器里没挂载
.env文件 →Dotenv直接抛异常，不是静默失败 - Nginx + PHP-FPM：FPM pool 配置中未设置
env[APP_ENV] = production，则即使.env存在，Web 请求也拿不到初始上下文 - crontab 执行 PHP 脚本时，默认
PATH极简，连php命令都找不到 ——phpdotenv根本没机会运行
真正关键的不是“装没装 phpdotenv”，而是搞清变量在哪一层生效、谁负责初始化、谁有权覆盖。一个 .env 文件解决不了 PATH 缺失、FPM 进程污染、crontab 环境剥离这些底层问题。
立即学习“PHP免费学习笔记（深入）”；
