Config::pull()仅加载指定配置文件的原始数组，不参与环境覆盖和合并；Config::get()获取当前生效的全部配置。
Config::pull() 只能获取一级配置文件的全部内容，不能取子项，也不能带点号；它和 Config::get('xxx.') 的行为不等价，但常被误用。
Config::pull() 的真实作用：按文件名加载整个配置数组
它本质是“按配置文件名读取该文件返回的完整数组”，比如 Config::pull('database') 等价于 include config/database.php 的返回值。不是从全局配置池里“筛选”出 database 下的所有键，而是直接加载那个 PHP 文件本身。
- 必须传入纯文件名（不含扩展名），且该文件必须存在于
config/目录下 - 传
'app'就加载config/app.php，传'cache'就加载config/cache.php - 不支持点号语法，
Config::pull('app.debug')会报错或返回 null - 返回的是原生数组，不会经过框架的二级键合并逻辑（比如不会自动把
database.connections.mysql合并进顶层database）
为什么 Config::pull('app') 和 Config::get('app.') 返回结果可能不同
因为 Config::get('app.') 是从已加载的全部配置中“提取所有以 app. 开头的键”，而 Config::pull('app') 只读 config/app.php 文件本身——如果其他配置文件（如 config/dev.php）里也定义了 app.app_debug，pull() 拿不到，get('app.') 能拿到。
- 环境配置覆盖后，
Config::get('app.app_debug')可能是true，但Config::pull('app')['app_debug']还是原始值 - 模块配置里的
app键（如app/admin/config/app.php）也不会被pull('app')加载 - runtime/config.php 中动态写入的
app.*配置，pull()完全不可见
什么时候该用 pull()，什么时候该用 get()
用 Config::pull() 的唯一合理场景是：你需要一份未被运行时修改、未被环境配置覆盖、干净原始的配置快照，比如做配置导出、生成文档、校验模板结构。
立即学习“PHP免费学习笔记（深入）”；
- 要读当前生效的配置 → 一律用
Config::get()或config()助手函数 - 要批量读某配置文件所有项且确保没被覆盖 → 用
Config::pull() - 要判断某个配置是否存在 → 用
Config::has('app_debug')，别用isset(Config::pull('app')['app_debug']) - 要改配置 → 用
Config::set('app_debug', false)，pull()不可写
真正容易被忽略的一点：pull() 返回的数组是「原始 include 结果」，它不参与 ThinkPHP 的配置合并机制。哪怕你在 config/dev.php 里写了 return ['app' => ['app_debug' => true]]，pull('app') 也看不到这个改动——它只认 config/app.php。这点在调试配置不生效时，最容易卡住。
