ThinkPHP 5.1.18 不建议使用动态配置，因其仅当次请求生效、无法持久化，且 app_debug 等关键安全配置被框架早期锁定、动态设置无效，易引发安全隐患与环境不一致问题。
ThinkPHP 5.1.18 不建议用动态配置，核心原因在于它只在当次请求中生效，无法持久化、不可靠，且部分关键配置根本无法被动态覆盖。
动态配置仅限单次请求有效
动态配置指在控制器或中间件中通过 config() 或 Config::set() 修改配置项，例如：
config('app_debug', false);这类操作不会写入任何配置文件，也不会影响后续请求。PHP-FPM 每次请求都是独立生命周期，重启后全部还原。对调试开关、路由规则、模板设置等依赖全局一致性的参数来说，这种“改了等于没改”。
多数安全与基础配置禁止运行时修改
ThinkPHP 5.1.18 明确规定：以下配置项必须静态定义在 config/app.php 中才生效，动态设置会被忽略：
立即学习“PHP免费学习笔记（深入）”；
-
app_debug（调试模式开关） -
app_trace（Trace 面板启用） -
url_route_must（路由强制匹配） -
default_module（默认模块） -
pathinfo_depr（URL 分隔符） -
default_filter（全局输入过滤）
框架在启动早期就已读取并锁定这些值，后续调用 config() 修改无效，但又不报错，极易造成“以为关了调试，其实没关”的安全隐患。
安全策略类配置必须静态固化
比如 XSS 防御相关的 template.autoescape 和 template.default_filter，需在 config/template.php 中明确开启：
'template' => [
'autoescape' => true,
'default_filter' => 'htmlspecialchars',
],若试图在控制器里 config('template.autoescape', true)，该设置不会注入到模板引擎初始化流程中，XSS 过滤形同虚设。
动态配置易引发环境不一致问题
开发时可能临时 config('database.hostname', '127.0.0.1')，但测试/生产环境若忘记还原，会导致数据库连错；更严重的是，多人协作中没人知道谁在哪改过什么，配置状态变成“黑盒”，排查问题成本极高。
不复杂但容易忽略
