C函数在ThinkPHP 5.1+中已被彻底移除，必须改用config()助手函数读写配置，其本质是think\Config的静态代理，支持点号分隔键名、运行时设置及环境配置合并，禁用C()可避免变量污染与并发安全问题。
ThinkPHP 5.1+ 中 C 方法已彻底移除，不能用
直接告诉你结果：C 函数在 ThinkPHP 5.1 及之后版本中已被完全删除，不是“不推荐”，是调用就报 Call to undefined function C()。它原本是 TP3/TP5.0 的全局配置读写快捷方式，但设计上存在变量污染、无法区分作用域、不支持动态加载等问题，所以官方砍掉了。
常见错误现象：升级到 TP5.1 或 TP6 后，原项目里大量 C('database.host') 全部挂掉；或者看到文档里还有 C() 示例，其实是旧版残留，别信。
- TP5.1 开始，配置必须通过
think\Config类或助手函数config()操作 - TP6 默认只保留
config()助手函数，think\Config仍可用但不推荐直接 new 实例 - 所有配置默认按文件加载（如
app/config/database.php），不再支持运行时随意C('key', $val)写入
用 config() 替代 C() 读取配置的正确姿势
config() 是 TP5.1+ 唯一推荐的配置访问方式，它本质是 think\Config 的静态代理，但更轻、更安全。
使用场景：读数据库配置、获取自定义参数、判断环境开关等。
立即学习“PHP免费学习笔记（深入）”；
- 读单个值：
config('database.hostname')（注意键名是点号分隔，不是斜杠） - 读整个配置组：
config('database')→ 返回数组 - 设置运行时配置（仅限当前请求）：
config('cache.type', 'redis')，但禁止在中间件/控制器外提前写，否则可能被后续配置覆盖 - TP6 中若启用了配置缓存（
php think optimize:config），config()读的是合并后的最终结果，不是原始文件
示例：
if (config('app_debug')) {
echo '开发模式';
}
为什么不能继续用 C() 的替代方案硬“恢复”它
有人会去 GitHub 找“兼容包”或自己封装一个 C() 函数，这很危险。
性能与兼容性影响：手动实现的 C() 往往绕过框架的配置合并逻辑（如环境配置覆盖、多应用配置隔离），导致本地开发和线上行为不一致；TP6 的配置系统还引入了 Swoole 下的协程安全要求，简单函数无法保证并发安全。
- TP5.1+ 的配置加载顺序是：基础配置 → 环境配置（.env）→ 应用配置 → 多应用配置 → 动态设置。硬加
C()容易跳过前几步 - TP6 的
config()支持延迟加载（Lazy Config），而模拟的C()通常是一次全载，内存占用高 - 如果你在 vendor 里改源码加回
C()，下次composer update直接消失，且违反 PSR-4 自动加载规范
复杂配置项（如二维数组、闭包、对象）读取要注意什么
不是所有配置都能用点号一层层读到底。比如 database.connections.mysql 可以，但 database.connections.mysql.host 在某些版本里会因键名含点被误切分。
容易踩的坑：
- 嵌套层级深时，建议先
$db = config('database.connections.mysql')，再取$db['host']，避免点号解析歧义 - 配置文件中写了闭包或对象（如自定义日志处理器），
config()读出来就是原样，不会自动执行——别指望它帮你实例化 - TP6.1+ 开始，
config()对null值更严格：如果配置项不存在，返回null而非空字符串或空数组，判空要写成config('xxx') !== null - .env 文件里的值默认是字符串，即使写
APP_DEBUG=true，config('app_debug')也是'true'，需手动filter_var(config('app_debug'), FILTER_VALIDATE_BOOLEAN)
事情说清了就结束。
