Config::pull('app')返回config/app.php的完整数组，不支持点号路径，仅接受一级配置名；与Config::get('app.')功能相似但语义更明确，且pull获取原始未合并配置，get可能含模块覆盖。
Config::pull('app') 返回的是 app.php 全部内容，不是子集
很多人误以为 Config::pull('app') 是“拉取某个键”，其实它对应的是整个配置文件——config/app.php 的返回值。这个函数不支持点号路径（比如 'app.debug'），只接受一级配置名（即文件名，不含 .php 后缀）。
它和 Config::get('app.') 行为一致，但语义更明确：pull 就是“把整个配置块拎出来”，get 带点号才是按路径查。
-
Config::pull('app')→ 返回config/app.php中 return 的数组 -
Config::pull('database')→ 返回config/database.php中 return 的数组 -
Config::pull('not_exists')→ 返回null，不会报错，也不触发默认值回退 - 不能写成
Config::pull('app.debug')，会直接返回null，因为没这级配置名
为什么 Config::pull 不支持二级路径？
因为 ThinkPHP 5.1 的配置体系里，“一级配置名” = 配置文件名。所有 config/*.php 文件被加载后，都挂载为顶层键，例如 app、database、log。二级键（如 app_debug、hostname）只是这些顶层数组内部的字段，不属于独立配置名。
pull() 设计初衷就是“整块取出”，避免嵌套遍历；而深层字段查询交给 get() 更合适。
立即学习“PHP免费学习笔记（深入）”；
- 想取
database.hostname→ 用Config::get('database.hostname') - 想取整个 database 配置用于初始化连接池 → 用
Config::pull('database') - 想判断某配置文件是否加载成功 →
is_array(Config::pull('cache'))比Config::has('cache.prefix')更可靠
Config::pull 和 Config::get('xxx.') 的实际差异
表面上两者都能拿到一整组配置，但底层行为不同：
-
Config::pull('app')是直接从已加载的配置容器中取出 key 为app的原始数组，不做任何合并或覆盖处理 -
Config::get('app.')是走通用 get 路径解析逻辑，末尾带点号会触发“获取该前缀下全部键值”，过程中可能混入模块配置或动态设置的覆盖项 - 在模块配置存在同名文件（如
application/admin/config/app.php）时，pull('app')只返回应用级的config/app.php，而get('app.')会合并模块级覆盖后的结果
所以如果你需要“原始未合并”的配置快照（比如做调试对比、序列化存档），pull() 更干净；如果要“最终生效”的配置，还是得用 get('xxx.')。
升级到 ThinkPHP 6.0 后 pull() 不能省略前缀了
TP5.1 允许 Config::pull('app') 这种写法，但 TP6.0 已移除对无点号前缀的兼容。升级时所有 pull() 调用必须显式传入完整路径，否则返回空：
- TP5.1 ✅
Config::pull('app') - TP6.0 ❌
Config::pull('app')→null - TP6.0 ✅
Config::pull('app.app_debug')或改用Config::get('app.')
这个变化容易被忽略，尤其在封装了配置读取工具类的项目里——一旦升级后没改，某些依赖 pull() 初始化的服务（比如日志驱动、缓存实例）会拿不到配置而静默失败。
