为什么ThinkPHP环境变量配置优先级高于配置文件【配置】

说到 ThinkPHP 环境变量和配置文件的优先级，很多人都会踩坑。明明在 config/database.php 里写好了数据库地址，结果连的却是 .env 里那个本地地址——这其实是框架设计上的一个必然结果。

.env 文件在 ThinkPHP 初始化早期就被加载并注入配置系统

ThinkPHP 并不是“边运行边读 .env”，而是在 App::init() 阶段——通常是 public/index.php 启动时——就调用 thinkinitializerEnv::init() 一次性解析 .env 文件，并把变量写入 PHP 的 $_ENV 和 $_SERVER。后续所有配置文件（比如 config/database.php）在加载时，只要用了 env('DB_HOST') 这类调用，拿到的就是这个已注入的值——它天然早于配置文件执行，所以优先级更高。

常见错误现象：config/database.php 明明写了 'hostname' => '192.168.1.100'，但连接却连向 127.0.0.1；根本原因就是 .env 里定义了 DB_HOST=127.0.0.1，且被 env('DB_HOST') 读取并覆盖了硬编码值。

env() 函数不是“读文件”，而是带白名单和前缀校验的环境变量访问器

env('DB_HOST') 不会去重新打开 .env 文件，它只是从 PHP 已有的 $_ENV 中取值，并经过框架预设的前缀白名单过滤（默认只允许 APP_、DB_、CACHE_ 等）。这意味着：

• 若你定义了 REDIS_URL=redis://prod，但没提前调用 thinkEnv::setPrefix(['REDIS_'])，env('REDIS_URL') 就会返回 null
• CLI 模式下，如果系统已通过 export REDIS_URL=redis://cli 设置了环境变量，env('REDIS_URL') 会直接返回该值，而不是 .env 里的
• env('db_host')（小写）或 env('Db_Host') 都无效，必须全大写 + 下划线：env('DB_HOST')

配置缓存让 .env 修改“看起来不生效”

ThinkPHP 把所有配置（包括 database.php 中通过 env() 计算出的结果）合并后写入 runtime/config.php。哪怕你改了 .env，只要没清缓存，框架下次启动仍会直接加载这个缓存文件——里面保存的是旧的 env() 结果。

所以必须手动清除：

• rm -rf runtime/config.php
• 或者执行 php think clear:config（TP6+）
• 注意：仅删 runtime/cache/ 不够，runtime/config.php 才是配置缓存主文件

多进程/长生命周期场景下 .env 只加载一次

Swoole 或常驻进程模式中，只有主进程在启动时调用一次 thinkinitializerEnv::init()；Worker 进程 fork 后不会重新读 .env，也不会响应文件变更。这意味着：

• 热更新 .env 文件对正在运行的 Worker 无效
• 修改后必须重启整个服务（如 php think swoole:restart），不能只 reload
• 若用 fastcgi_param APP_ENV prod 在 Nginx 中设置了环境，框架会跳过 .env 加载，直接使用该值——此时 .env 文件本身已被忽略

真正容易被忽略的点在于：你以为改了 .env 就生效，其实它只是一次性注入的快照；后续所有配置行为都基于这个快照，而缓存和进程模型会让这个快照“滞留”很久。