ThinkPHP版本升级中的命名空间变化_代码自动化重构工具-ThinkPHP-PHP中文网

thinkphp 6+ 命名空间强制细分，核心类移入 thinkacade，异常类移入 thinkexception，容器类进 thinkcontainer；需手动注册 facade 提供者、禁用 new db()、废除 loader::import() 并改用 psr-4 自动加载。

thinkphp版本升级中的命名空间变化_代码自动化重构工具

ThinkPHP 6+ 的命名空间从 `think` 变成了 `thinkacade` 和 `thinkexception` 等细分路径

TP5.1 默认用 thinkDb、thinkCache 这类顶层命名空间，TP6 开始强制拆分——核心类全进了 thinkacade，异常类移入 thinkexception，容器相关进 thinkContainer。这不是可选配置，是框架硬编码的自动加载规则变化。

实操建议：

全局搜索替换 use thinkDb; → use thinkacadeDb;，但别盲目替换所有 think 开头的 use，比如 thinkRequest 在 TP6 里已废弃，得换 thinkacadeRequest 或直接注入 thinkRequest 实例（注意：后者不是 facade）
thinkModel 不再是基类，必须换成 thinkModel（TP6 保留同名类但语义不同）或更推荐的 thinkmodelPivot / thinkmodelconcernAttribute 等具体路径
TP6 移除了 thinkLog facade，改用 thinkacadeLog，但底层日志驱动初始化方式也变了，光改命名空间不够，还得检查 config/log.php 是否含 'default' => 'file' 这类旧键名（TP6 要求 'default' => 'single'）

自动替换工具跑完后，`Facade` 类静态调用仍报 `Class not found`

常见错误现象：脚本把 Db::table() 前的 use 改对了，运行时却提示 Class 'thinkacadeDb' not found。根本原因不是命名空间写错，而是 TP6 的 Facade 必须在容器中注册绑定，而升级后 config/app.php 里的 'providers' 数组默认只加载了核心 Facade 提供者，你自定义的或插件里的 Facade 没被扫描。

实操建议：

检查 app/provider.php（TP6 新增）是否包含对应 Facade 的 provider，例如 thinkacadeDb 对应 thinkserviceDbService，没写就得手动加
如果用了第三方扩展（如 topthink/think-queue），它的 Facade（如 thinkacadeQueue）不会自动注册，需在 app/provider.php 中显式追加 thinkserviceQueueService::class
运行 php think clear:config 清缓存，TP6 的配置合并逻辑变了，旧缓存可能卡住新 provider 注册

批量替换时把 `new hinkDb()` 这类实例化写法也误替换了

TP6 彻底移除了 thinkDb 类的构造能力，Db 只能作为 Facade 静态调用。但老代码里可能有 new hinkDb() 或 new Db()（配合 use thinkDb;），这类写法在 TP6 下必然报错，且自动化工具无法区分“静态调用”和“实例化”，容易一刀切替换出错。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

实操建议：

禁用全局正则替换 new Db()，改用 IDE 的结构化搜索（如 PHPStorm 的 “Search Structurally”）匹配 new Db() 并人工确认上下文
真正需要实例化的场景（如多数据库连接），应改用容器获取：app('db')->connect($config)，而不是 new 任何 Db 类
注意 hinkdbConnection 是 TP6 里真正的连接类，但它不接受裸 new，必须通过 app('db') 或 Db::connect() 创建

TP5.1 的 `Loader::import()` 和手动 `require` 在 TP6 下失效

TP6 废弃了所有手动加载机制，完全依赖 Composer PSR-4 自动加载。如果你的代码里还留着 Loader::import('org.util.StringUtil') 或 require_once APP_PATH . 'common/util/StringUtil.php';，升级后这些文件根本不会被引入，也不会报错，只是静默跳过——直到某处调用 StringUtil::xxx() 才爆出 Class not found。

实操建议：

删掉所有 Loader::import() 调用，把对应类按 PSR-4 规范重命名并放对位置，例如 appcommonutilStringUtil 对应 app/common/util/StringUtil.php
检查 composer.json 的 "autoload" 配置，确保新增的目录已加入 "psr-4" 映射，例如：
```
"psr-4": {
    "app\": "app/"
}
```
运行 composer dump-autoload，TP6 不再读取 Loader 的映射表，只认 Composer 生成的 vendor/composer/autoload_psr4.php