推荐分层策略：.env存环境相关值并用Env类加载，配置文件写共用逻辑，禁止运行时config()写配置；配置工厂需用Container闭包延迟加载；.env仅初始化时读取一次，config:clear不重载.env；多应用需显式指定应用名避免污染。
配置项该放哪：环境变量 vs 配置文件 vs 运行时注入
ThinkPHP 的配置管理核心矛盾不是“怎么读”，而是“从哪来”——不同来源的优先级和加载时机直接决定行为是否可预期。config() 读取的是合并后的最终结果，但源头混杂时，你根本不知道 database.host 是来自 .env、config/database.php 还是某次手动 config('database.host', '127.0.0.1') 的覆盖。
推荐分层策略：
-
.env只存真正环境相关值（如APP_DEBUG、DB_HOST），且必须用Env类加载，不能靠框架自动识别（否则测试环境可能误读生产.env） - 配置文件（如
config/cache.php）只写逻辑固定、多环境共用的部分，比如缓存驱动类型、前缀格式 - 绝对避免在控制器或中间件里用
config()写配置——它会污染全局状态，导致并发请求间配置互相覆盖
配置工厂怎么写才不踩坑：用闭包延迟加载真实依赖
ThinkPHP 支持通过闭包定义配置项（即“配置工厂”），但很多人直接在闭包里 new 实例或调用静态方法，结果启动阶段就报错——因为此时容器还没初始化完，Db::connect() 根本不可用。
正确做法是把依赖推迟到首次访问时才解析：
立即学习“PHP免费学习笔记（深入）”；
- 闭包参数必须声明为
Container $container，而不是直接调用app()或Db:: - 闭包体内只返回一个函数，不执行任何实际操作；真正的实例化交给返回的函数内部做
- 示例：
'cache' => function (Container $container) { return function () use ($container) { return new RedisCache($container->get('redis')); }; }
配置加载顺序和覆盖规则：为什么 config:clear 有时没用
ThinkPHP 加载配置的顺序是：thinkphp/tpl/config/ → config/ → .env → 运行时 config() 调用。但关键点在于：.env 的值仅在应用初始化早期被读取一次，之后修改文件不会自动重载；而 config:clear 清的是缓存（runtime/config.php），不是重新解析 .env。
常见错误现象：
- 改了
.env但数据库还是连旧地址 → 检查是否启用了配置缓存（config_cache开关），并确认runtime/config.php是否存在且内容已更新 - 本地开发没问题，部署后配置失效 → 很可能是服务器上
.env权限不对，或者 PHP-FPM 用户无法读取该文件 - 使用
Config::load()手动加载自定义配置时，未指定第二参数$type，导致被当成默认配置合并，而非独立命名空间
多应用模式下配置隔离失效：别让 console 应用污染 http 配置
ThinkPHP 多应用模式下，config/ 目录结构是 config/app_name/，但默认的 config() 函数不感知当前应用上下文。如果你在 console 应用里执行 config('database.host', 'localhost')，这个值会进入全局配置池，随后 http 请求也可能读到它。
解决方式很直接：
- 所有跨应用的配置操作，必须显式指定应用名：
config('database.host', 'localhost', 'console') - 避免使用无参
config()获取全部配置——它返回的是全量合并结果，包含其他应用的私有配置，容易引发混淆 - 如果某个配置只属于特定应用（如
console.schedule），务必放在config/console/schedule.php，并通过config('schedule', [], 'console')显式读取
配置从来不是“写完就跑”的事，最麻烦的永远是加载时机、作用域边界和缓存生命周期——这几个地方一旦松动，问题就会藏在看似无关的模块里反复冒头。
