ThinkPHP 5.1 在 PHP 8.2 下无法直接运行，需优先处理动态属性警告、__invoke签名校验、Facade返回类型缺失及MySQL驱动配置错误：升级至5.1.42+可修复动态属性问题；全局清除mysql_*函数调用并改用Db::query()；为__callStatic补mixed返回类型或改用依赖注入；确保database.php中type为'pdo_mysql'而非'mysqlnd'。
ThinkPHP 5.1 在 PHP 8.2 下无法直接运行，不是“报错就修”，而是多个底层机制冲突叠加——动态属性警告、__invoke签名校验、Facade 返回类型缺失、以及 MySQL 驱动配置错误会同时触发，必须按优先级逐层处理。
PHP 8.2 报 Deprecated: Creation of dynamic property 是什么问题
TP 5.1 的 Request、Model 等类在运行时给未声明的属性赋值（如 $this->param = []），PHP 8.2 默认触发弃用警告。这不是日志噪音，它会阻断部分中间件执行，且可能被框架内部逻辑误判为异常。
- 最稳妥解法：升级到
thinkphp5.1.42+（官方已修复核心类的动态属性问题） - 若不能升级，需手动检查所有自定义类，把类似
$this->data = []改为显式声明：protected $data = []; - 临时屏蔽（仅限调试）：在
public/index.php开头加error_reporting(E_ALL ^ E_DEPRECATED)，但上线前必须清掉 - IDE 或 PHPStan 提示 “Dynamic property” 的地方，90% 是真实兼容性风险点，别跳过
mysql_connect() 报 Fatal error: Call to undefined function 怎么办
PHP 8.2 彻底删除了 mysql_connect() 及所有 mysql_* 函数——不是弃用，是代码里根本找不到这个函数名。哪怕只有一处残留调用，整个应用启动失败。
- 全局搜索：
grep -r "mysql_" app/ extend/，重点看mysql_connect、mysql_query、mysql_fetch_array - 确认是否真在用：绝大多数 TP 5.1 项目实际走的是
\think\Db，这些mysql_*调用往往是历史插件或旧模块遗留 - 替换方案：
mysql_query("SELECT * FROM user")→\think\Db::query("SELECT * FROM user") - 检查
config/database.php中'type'值：必须是'mysql'或'pdo_mysql'，绝不能是'mysqlnd'（该驱动名在 PHP 8.2 已不存在）
控制器 __invoke 方法调用失败报 TypeError
PHP 8 强化了可调用对象的类型校验。TP 5.1 中手动实现 __invoke 的控制器（非继承 think\Controller 的标准写法），若参数没声明类型，PHP 8.2 直接拒绝调用。
立即学习“PHP免费学习笔记（深入）”；
- 定位文件：通常在
app/controller/下某控制器类中，方法签名类似public function __invoke($request) - 修复方式：改为
public function __invoke(\think\Request $request)，补全类型提示 - 如果控制器继承了
think\Controller且没重写__invoke，则无需改动；问题集中在自定义实现该方法的场景 - 注意：不要写成
public function __invoke($request = null)，PHP 8.2 仍会因类型缺失报错
Facade 静态调用刷屏 Deprecated: Return type 怎么压
Cache::get()、Log::info() 这类静态门面调用，在 PHP 8.1+ 会因 __callStatic 缺少返回类型声明而持续输出弃用警告。它不中断运行，但日志爆炸、掩盖真正问题。
- 快速修复：在
thinkphp/library/think/facade/Cache.php等对应文件中，给__callStatic补上返回类型：public static function __callStatic($method, $params): mixed - 更彻底的做法：改用依赖注入，例如把
Cache::get('key')换成app('cache')->get('key')，完全绕过静态门面 - 顺手检查
composer.json中"php"约束是否已更新为"^8.2"，否则composer update可能跳过适配包
真正难处理的不是报错，而是那些不报错却结果错位的地方：比如 isset($arr['key']) 在嵌套空数组下行为偏移、日期格式化返回空字符串、或者 array_key_exists(null, []) 在 PHP 8.2 返回 false（旧版是 true）——这些必须靠单元测试覆盖关键路径，而不是靠肉眼排查。
