ThinkPHP 6.1+ 中 $this->config 动态属性报错是因为框架彻底移除了魔术方法代理，必须改用 Config::get() 和 Config::set() 显式访问配置，且不可在构造函数中调用，避免初始化失败或逻辑错误。
ThinkPHP 6.1+ 中 $this->config 动态属性为什么报错
因为从 ThinkPHP 6.1 开始，$this->config 这类动态属性访问被彻底移除——不是弃用警告，是直接抛出 InvalidArgumentException 或 Undefined property 错误。框架底层不再代理控制器/模型里的魔术方法去读取配置对象，配置必须显式获取。
用 Config::get() 和 Config::set() 替代 $this->config
所有原来写成 $this->config['app_debug'] 或 $this->config->app_debug 的地方，都得换成静态调用。注意：这不是“换种写法”，而是重构逻辑入口点。
-
Config::get('app_debug')读取单个配置项，支持点号路径（如database.hostname） -
Config::set('app_debug', true)写入配置，仅对当前请求生命周期有效 - 若需在中间件或服务启动时预设配置，请改用
Config::load()加载额外配置文件，而非运行时覆盖 - 不要在构造函数里调用
Config::get()—— 配置容器可能尚未初始化，会返回空或触发异常
控制器里频繁读配置？封装成 protected 方法更安全
直接满屏 Config::get() 不仅难维护，还容易漏掉默认值和类型校验。尤其当多个方法共用同一组配置时，硬编码路径极易出错。
- 把常用配置提取为
protected function getAppConfig(): array，内部统一用Config::get()+??提供默认值 - 避免用
Config::set()修改核心配置（如app.app_name），某些配置在应用启动后已固化，修改无效且无提示 - 测试环境下临时改配置，优先用环境变量（
.env）而不是代码里Config::set()，否则容易遗忘并带入生产
自定义配置类继承 think\Config 的风险
有人想“恢复”旧习惯，自己写个基类重载 __get()，把 $this->config 又变回来。这看似省事，实则埋雷。
立即学习“PHP免费学习笔记（深入）”；
- ThinkPHP 6+ 的
Config类本身已不支持链式代理，强行继承并重写魔术方法可能绕过配置合并逻辑，导致多级配置（如环境配置覆盖基础配置）失效 - IDE 无法识别你自定义的动态属性，类型提示丢失，
phpstan或psalm会持续报错 - 升级到 TP7 时这类 hack 几乎必然崩溃，官方不会再兼容此类用法
真正麻烦的不是改几行代码，而是那些散落在闭包、事件监听器、命令行指令里的隐式配置访问——它们不会报错，但会静默返回 null，直到某个功能突然不生效才暴露出来。
