ThinkPHP 不提供配置管理接口，config() 仅内存生效且不持久化；安全动态配置需白名单校验、权限控制、数据库存储与缓存清理。
config 函数和 Config 类不是接口，也没有“配置管理接口”这个内置概念——ThinkPHP 不提供运行时暴露 HTTP 接口来读写配置的功能，强行实现它等于绕过框架安全机制，直接暴露敏感配置项。
如果你真需要一个「配置管理页面」或「后台动态修改配置」能力，必须自己封装，且要严格控制权限、来源、字段白名单和持久化方式。
为什么不能直接用 config() 暴露成 API？
因为 config() 是运行时内存级操作，修改后只在当前请求生命周期生效，重启即丢失；更危险的是，若未加校验就允许任意键名写入（比如 config('database.hostname', $_POST['host'])），攻击者可篡改数据库连接、关闭调试模式、甚至注入恶意中间件。
如何安全地实现配置项的读取与更新？
仅限有登录鉴权 + 管理员角色的后台场景，且必须满足以下条件：
- 所有可读/可写的配置项必须硬编码在白名单数组中，例如：
['app_debug', 'default_lang', 'captcha.state'] - 写入前必须验证值类型（布尔/字符串/整数）和格式（如邮箱、URL、JSON 字符串需
json_decode($v, true)校验） - 不直接调用
config($key, $value)，而是写入到独立配置文件（如runtime/conf/admin_set.php），再通过Config::load()重新加载 - 禁止写入任何以
database.、cache.、.env相关路径开头的键，这些属于高危配置域
Config::load() 和 config() 的行为差异
前者是文件加载器，会合并数组并覆盖旧值；后者只是对已加载配置的内存读写。常见误用：
- 在控制器里执行
config('log.level', 'debug')→ 本次请求日志级别变 debug，但不影响其他请求，也**不会写回文件** - 用
Config::load('admin_set')加载自定义配置 → 必须确保该文件return [ ... ]，且路径在CONF_PATH或config/下 -
Config::set()在 TP6 中已被废弃，TP5.1+ 推荐统一用config($key, $value)，但注意它不触发文件写入
真正能落地的配置持久化方案
不要试图让 config 类承担存储职责。推荐做法是：
立即学习“PHP免费学习笔记（深入）”；
- 新建数据表
sys_config，字段包括name（唯一标识）、value（JSON 存储）、type（string/int/bool）、remark - 后台控制器读取时：用
Db::name('sys_config')->where('name', 'in', $whitelist)->select() - 更新时：先校验
$data['name']是否在白名单，再json_encode($data['value'])写入，最后调用Cache::clear('config')清除配置缓存 - 全局生效需在
app\common\behavior\ConfigInit行为中，于每次请求开始时从数据库拉取并config($k, $v)注入内存
