Config::set()在ThinkPHP6+中写入配置仅修改内存副本，不影响已初始化组件；数据库动态切换应使用Db::setConnectConfig()注册连接后调用Db::connect()。
Config::set() 在运行时写配置会失效
它不是“不能用”，而是写了也大概率不生效。ThinkPHP 6+ 的配置系统在应用初始化阶段（think\App::initialize() 之前）就完成合并并固化到内存中，后续调用 Config::set() 只会改单例里的数组副本，但已初始化的组件（如数据库连接器、日志驱动、缓存实例）根本不会重新读取这个新值。
常见错误现象：
-
Config::set('database.connections.mysql.host', '192.168.1.100')执行后，Db::connect('mysql')依然连老地址 - 中间件里修改
config('app.timezone')，但date()输出没变 - 日志级别改了，
Log::info()却依旧不输出——因为日志驱动早已按旧配置启动
Config::set() 和 config() 全局函数行为不一致
很多人误以为 config('key', $value) 是 Config::set() 的简写，其实不是：config() 函数在 TP6 中已被废弃写入能力，只保留读取；而 Config::set() 虽然存在，但它是面向开发者的“调试接口”，不是运行时配置更新机制。
关键差异：
立即学习“PHP免费学习笔记（深入）”；
-
config('app_debug', true)→ 静默失败，返回null或原值，无报错 -
Config::set('app_debug', true)→ 能写进 Config 单例，但think\facade\App等依赖配置的门面类不会响应变化 - 两者都不影响
env()、input()、路由解析等已加载模块的行为
真正需要动态配置时该用什么
硬编码配置 + Config::set() 组合，解决不了任何生产级动态需求。微服务或租户场景下，必须绕过配置系统本身，直击组件实例。
实操建议：
- 数据库连接动态切换：用
Db::setConnectConfig('tenant_db', $config_array)注册新连接，再Db::connect('tenant_db')—— 这是唯一进连接池的运行时方式 - 缓存驱动切换：不要改
cache.default，而是直接 new 一个Redis实例或调用Cache::store('redis')->get() - 环境变量注入：在
config/database.php里写'hostname' => env('DB_HOST', '127.0.0.1')，而不是靠运行时 set - 配置中心集成：Nacos/Apollo 返回 JSON 后，解析出
$config数组，再批量传给Config::set($config, 'database')—— 但必须确保此时还没执行Db::connect()，否则白干
容易被忽略的副作用
哪怕你成功用 Config::set() 改了某个键，也可能引发隐性问题：
- 多请求并发时，不同协程/线程看到的 Config 单例状态可能不一致（尤其 Swoole 场景）
- 某些扩展（如 think-swoole）会缓存配置快照，
Config::set()完全无效 - IDE 和静态分析工具无法识别运行时 set 的键，导致类型提示丢失、重构风险升高
- 测试时 mock 配置变得困难——你得同时 mock Config 单例和所有下游组件
最稳妥的做法，是把所有可变配置提前收口到服务容器或上下文对象里，而不是寄希望于改全局配置单例。
