ThinkPHP动态配置是内存级、仅当前请求生效的运行时覆盖，优先级最高但不持久；静态配置是磁盘文件中的持久化规则，按惯例→应用→模块→动态顺序加载，对所有请求长期有效。
ThinkPHP 的动态配置和静态配置文件，根本区别在于生效时机、作用范围和存储方式——一个只在当前请求内存中起效，另一个写在磁盘上、对所有请求长期有效。
动态配置：只活这一次
动态配置是运行时用 config() 或 Config::set() 临时设置的值，比如：
config('cache.type', 'redis');Config::set('app_debug', true);
它不修改任何 PHP 文件，也不写入磁盘，仅存在于当前 HTTP 请求的生命周期内。请求一结束，配置就自动还原为原始值（来自 config/app.php 等静态文件）。适合调试接口、按需切换缓存驱动、临时延长某个请求的超时时间等场景。
注意：部分核心参数（如 app_debug、app_trace）在动态配置中无法生效，它们必须在应用配置文件中定义，框架启动阶段就已锁定。
静态配置文件：持久生效的基础规则
静态配置文件是真实存在的 PHP 文件，例如：
-
config/app.php（应用基础配置） -
config/database.php（数据库配置） -
config/cache.php（缓存配置） - 或通过
'extra_config_list' => ['sms', 'alipay']引入的独立配置文件
这些文件返回标准的 PHP 数组，被框架按“惯例 → 应用 → 模块 → 动态”顺序加载合并。修改后需保存文件，且对后续所有请求都生效（除非被更高优先级的动态配置覆盖）。它是项目稳定运行的配置基线。
别把“动态写入配置文件”当成动态配置
有人会用 file_put_contents() 把新数组写进 config/database.php，这属于运行时修改静态文件，不是动态配置。它需要目录可写权限，且生成的内容必须是合法 PHP 返回语句（如 ），否则下次加载直接报错。这种方式风险高、不推荐用于生产环境，仅适用于极少数后台管理类功能（如运营后台修改第三方密钥）。
怎么选？看需求是否要“跨请求持续”
如果只是让某次 API 返回带 trace 信息、或让某个用户请求走 Redis 缓存——用动态配置；
如果要让整个站点默认使用 MySQL8、开启模板缓存、统一设置时区——改静态配置文件。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
