thinkphp中.env优先于config/*.php，但前提是成功加载：需确保文件位于项目根目录、utf-8无bom编码、cli模式下手动调用dotenv::safeload()、变量名全大写下划线、配置文件中统一使用env()函数读取，并清除runtime缓存。
.env 优先于 config/*.php 文件，但仅在它被成功加载且变量名符合规范的前提下。
这个“优先”不是无条件的——它依赖加载时机、白名单控制、缓存状态和 CLI/Web 环境差异。很多“改了 .env 没生效”的问题，其实根本没走到覆盖那步。
为什么 .env 看似写了却没覆盖 config/database.php？
ThinkPHP 不是“读到 .env 就立刻替换”，而是按固定阶段合并配置：.env 的值只在应用初始化早期被解析一次，然后参与合并。常见失效原因包括：
-
.env文件不在项目根目录（即含app/、config/、composer.json的目录） - 文件编码带 BOM（尤其 Windows 记事本保存），导致
Dotenv::safeLoad()静默失败 - CLI 模式下未手动加载：Web 请求走
public/index.php自动加载，但php think命令默认不触发，需在think文件末尾补\Dotenv\Dotenv::createImmutable(__DIR__)->safeLoad(); - 变量名不符合大写+下划线规则：例如
db_host或DB-HOST全部无效，必须是DB_HOST - 框架白名单限制：直接调用
Env::get('DB_HOST')可能返回null，因 ThinkPHP 默认只放行APP_ENV、APP_DEBUG等少数键；应统一用env('DB_HOST', '127.0.0.1')函数读取
.env 覆盖的是整个配置块，不是字段级合并
以数据库为例：ThinkPHP 8 中，只要 .env 定义了 DB_NAME，整个 connections.mysql 配置就会被全量替换，config/database.php 里对应的 'database' => 'test' 直接作废。这不是“字段覆盖”，而是“块级丢弃+重建”。
-
config/database.php中必须全部使用env('DB_HOST', '127.0.0.1')形式，不能留死值 - 多库场景下，
.env里加DB2_HOST、DB2_NAME，再在database.php的connections数组中定义mysql2连接项，每个字段仍要调env() -
.env不支持数组或嵌套结构，像DB_SLAVE=[...]这种写法会被忽略
改完 .env 为什么还是连旧库？
因为运行时缓存没清，或者缓存机制被启用后跳过了重新解析逻辑。
- 必须删除
runtime/config.php（这是合并后的最终配置缓存） - 同时清空
runtime/cache/下的内容，避免其他缓存干扰 - 如果开启了配置缓存优化（如执行过
php think optimize:config），则仅删文件不够，需重新生成或禁用该开关 - 注意：修改
.env后，Web 服务无需重启，但 CLI 命令（如迁移、队列）必须确保下次执行时已加载新.env
真正容易被忽略的点是：.env 的优先级只在“加载成功”之后才起作用；而它的加载本身，是最脆弱的一环——无报错、无日志、静默失败是常态。
验证是否加载成功，最直接的方式是写一行 var_dump(env('DB_HOST')); 在控制器里看输出，而不是靠“我以为它应该生效”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
