Config::set()和config()仅在当前请求生命周期内修改配置，不持久化、不写入文件，作用域限于当前HTTP请求或CLI进程，优先级高于配置文件但请求结束即丢失。
Config::set() 或 config() 只影响当前请求生命周期，不会写入文件、不持久化，也不是“覆盖配置文件”——它只是往运行时配置容器里塞了个新值。
Config::set() 和 config() 的实际行为差异
两者本质一样：Config::set('app_debug', true) 等价于 config('app_debug', true)。框架底层都调用同一个配置管理器的 set 方法。
- 作用域严格限定在当前 HTTP 请求或 CLI 进程内，请求结束即丢失
- 优先级高于 config.php、extra/*.php 等文件加载的配置（因最后加载）
- 对数组类配置（如
database.connections）是递归合并，不是全量替换 - 若 key 已存在且为字符串，新值直接覆盖；若原值是数组而你传字符串，会报类型不匹配警告（TP6+ 有 stricter 模式）
为什么改了 config() 但 var_dump(config('xxx')) 还是旧值？
常见错误是：先调用 config('key', 'new')，再用 config('key') 读取，却没意识到中间可能被其它逻辑重置过 —— 尤其是 Config::load()、think\facade\Config::reset() 或模块初始化时重新合并了配置。
- 检查是否在
config()调用后，又执行了Config::load('xxx.php')，这会导致整个配置区被重载 - 确认没有在中间件、事件监听器或模型初始化中调用了
Config::reset() - TP6 中
config()助手函数默认操作的是'default'配置作用域，如果你手动切换过作用域（如Config::setScope('admin')），必须显式指定作用域才能读到：config('key', null, 'admin')
想让 config() 修改真正“生效到下次请求”？别直接写文件
硬用正则替换 PHP 配置文件（如网上流传的 setConfig() 函数）风险极高：语法破坏、引号嵌套错乱、多维数组无法处理、并发写入冲突、无事务回滚 —— 2026 年还在这么干，基本等于给线上服务埋雷。
立即学习“PHP免费学习笔记（深入）”；
- 真正可靠的做法是：把需要动态变更的配置项抽离到数据库 + 缓存（如 Redis）中，启动时通过
Config::set()注入 - 如果非得落盘，应生成独立的
runtime/config/dynamic.php，用var_export()安全序列化，再由Config::load()加载，而不是正则硬改config.php - 务必配合
clear_cache命令或Cache::clear('config')清除配置缓存，否则即使文件写了，TP 仍读旧缓存
最常被忽略的一点：TP 的配置缓存是按「文件路径」哈希的，哪怕你改了 config/app.php 内容，只要文件 mtime 没变（比如 FTP 上传覆盖但时间戳未更新），缓存就不会刷新 —— 所以动态写入后，一定要 touch 文件或强制清缓存。
