app_debug等参数必须在应用启动前静态配置，运行时调用config()或Config::set()无效；它们参与框架早期生命周期构建，如错误处理、路由解析、输入过滤等底层行为，初始化后即锁定。
ThinkPHP 中有一部分配置项属于“启动即锁定”类型，必须在应用初始化前、通过静态配置文件（主要是 config/app.php）定义，运行时用 config() 或 Config::set() 修改是无效的——框架会直接忽略，不会报错，但也不会生效。
只能在 app.php 中设置的关键配置
这些参数控制框架最底层行为，一旦启动就不可变更：
-
app_debug：调试模式开关。设为
true才能显示错误详情、Trace 面板等；运行时修改无效果，生产环境必须静态设为false -
app_trace：是否启用 Trace 调试面板。依赖
app_debug为true，动态设置不触发界面加载 -
default_filter：全局输入过滤规则（如
'htmlspecialchars,strip_tags'）。控制器中调用config('default_filter', ...)不会改变实际过滤行为 -
pathinfo_depr：URL 路径分隔符（如
'-'支持/user-info-list）。影响路由解析核心逻辑，仅首次加载 config/app.php 时读取 -
url_route_must：路由是否强制匹配。设为
true后未定义路由直接 404，运行时切换无法绕过该机制 - app_multi_module：是否启用多模块模式。决定整个应用的模块调度结构，初始化后不可更改
为什么这些不能动态改
它们不是普通业务参数，而是参与框架生命周期早期构建的“元配置”。例如：
-
app_debug决定是否加载think\Debug类、是否开启异常处理器、是否写日志到runtime/log/ -
pathinfo_depr在请求进入路由解析前就被固化，影响Request对象对 URL 的初步拆解 -
default_filter绑定在Input类的静态属性上，初始化后所有输入都走同一套过滤链
容易误以为能改、实则无效的操作
以下写法看似合理，但在 ThinkPHP 5.1+ 中均不生效：
- 在控制器中写
config('app_debug', false)—— 值被存入配置容器，但调试机制早已启动，无实际作用 - 在中间件里调用
Config::set('url_route_must', false)—— 路由匹配流程已完成，该设置对当前请求无效 - 用
env('APP_DEBUG', 'false')在配置文件中覆盖 ——.env可改APP_DEBUG，但框架只在启动阶段读一次，且仍需config/app.php中存在对应键才参与合并
替代方案：需要灵活控制怎么办
如果业务确实需要“运行时切换类似行为”，建议绕过原生配置，改用其他机制：
- 调试信息展示 → 自定义日志通道或响应头标记，不依赖
app_debug - URL 分隔风格切换 → 用路由规则重写（
Route::rule()）或前端统一处理，而非改pathinfo_depr - 输入过滤策略差异 → 在具体方法中手动调用
htmlspecialchars()或封装校验器，不依赖全局default_filter - 模块启用开关 → 用权限系统或配置表控制模块访问，而不是动态开关
app_multi_module
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
