必须在自动加载器生成前加载环境变量——正确做法是利用 Composer 的 pre-autoload-dump 钩子执行 Dotenv::createImmutable(__DIR__, ['.env', '.env.local'])->safeLoad()，确保所有类加载前 $\_ENV 已就绪。
phpdotenv 加载时机不对，$_ENV 在框架初始化后才可用？那说明环境变量注入太晚了——必须在自动加载器生成前就生效。
为什么 Dotenv::load() 放在入口文件里是错的
常见错误现象：DatabaseConnection 构造时依赖 getenv('DB_HOST')，但此时 .env 还没加载，结果连接参数为空或 fallback 到默认值，报错却指向数据库驱动层，实际根因藏得深。
根本原因在于 Composer 的自动加载机制早于你写的入口逻辑。一旦某个类（比如配置工厂）被 composer/autoload_psr4.php 提前加载，它内部读取的 $_ENV 就是原始空状态。
- 框架（如 Laravel、ThinkPHP 8）的配置引导流程常在
vendor/autoload.php后立即触发，此时Dotenv还没跑 - CLI 命令（如
php artisan tinker）可能绕过 Web 入口，导致重复加载或完全遗漏 -
$_SERVER和$_ENV是 PHP 超全局，一旦写入就不可逆；多次调用Dotenv::load()可能覆盖已有值，引发意外交互
用 pre-autoload-dump 事件提前注入
Composer 提供的 pre-autoload-dump 是唯一能确保「所有类可见前，环境已就绪」的钩子。它在生成 vendor/autoload.php 前执行，天然规避加载顺序问题。
操作步骤：
- 在项目根目录创建
scripts/load-env.php，内容为：<?php $dotenv = Dotenv\Dotenv::createImmutable(__DIR__); $dotenv->safeLoad();
- 修改
composer.json的scripts段："scripts": { "pre-autoload-dump": "php scripts/load-env.php" } - 运行
composer dump-autoload或任意触发 autoload 更新的操作（如composer install）
注意：safeLoad() 比 load() 更稳妥——当 .env 不存在时不报错，适合多环境部署。
composer config --global 不影响项目级 .env 注入
有人误以为改 Composer 全局配置能控制环境变量加载，其实完全无关。composer config --global 只管 Composer 自身行为（如缓存路径、镜像源），不触碰应用运行时的 $_ENV。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正要区分的是两层配置：
-
composer.json里的config.platform.php：仅用于依赖解析时模拟 PHP 版本，不影响运行时 -
.env文件内容：由phpdotenv解析并写入超全局，属于应用层逻辑 - 若需跨项目复用 dotenv 配置逻辑，应封装成私有 Composer 插件，而非依赖全局 config
多个 .env 文件共存时的加载顺序陷阱
开发中常需要 .env.local 覆盖 .env，但 Dotenv::createImmutable() 默认只读一个文件。手动叠加容易漏掉 override 参数。
正确做法是显式指定：
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__, ['.env', '.env.local']); $dotenv->safeLoad();
否则 .env.local 中的同名变量不会生效——这不是 bug，是 createImmutable 的设计约束：它默认禁用覆盖，必须靠文件列表顺序 + safeLoad() 的底层合并逻辑来实现。
最易被忽略的一点：这个文件列表必须按「从通用到具体」排序，.env.local 得放在最后，否则会被前面的文件覆盖。
