thinkphp插件冲突导致白屏等功能异常，须立即禁用插件、清runtime缓存、查runtime/log与php错误日志，再分文件覆盖、钩子重复、数据库表名硬编码三类排查，并用二分法定位冲突组合。
ThinkPHP项目安装插件后出现白屏、功能失效、后台无法登录或数据库报错，说明插件已与其他模块产生冲突，必须立即定位并隔离问题源，否则可能引发连锁故障。
第一步：紧急禁用可疑插件
如果后台还能访问，直接进入「插件管理」界面，找到最新安装的插件，点击「禁用」。这一步能快速验证是否为该插件导致问题——禁用后页面恢复正常，基本可锁定目标。
若后台已无法进入，需通过FTP或SSH手动操作：进入app/plugin/目录（TP6+）或extend/目录（部分老插件），找到对应插件文件夹，重命名为plugin_name_bak。注意：【不要删除，保留原始结构以便回溯】。
修改后清空runtime/下所有子目录（特别是cache/和log/），再刷新页面。缓存未清可能导致禁用不生效。
第二步：查日志定位具体错误点
打开runtime/log/目录，按日期查找最新日志文件（如2026-06-12.log），用文本编辑器搜索关键词Fatal error、Class not found、Call to undefined function或SQLSTATE。
若日志为空，检查config/app.php中'log' => ['level' => 'error']是否被误设为'notice'或'debug'——这会导致关键错误被过滤。临时改为'error'并重启请求，日志会立刻变详细。
同时查看PHP错误日志：执行php --ini找到php.ini路径，确认error_log指向位置，打开该文件查看是否有PHP Fatal error堆栈。
第三步：分类型排查冲突根源
方法一：文件级覆盖冲突
某些插件会直接修改thinkphp/library/think/下的核心类（如Request.php或App.php）。用IDE全局搜索class Request extends，看是否在插件目录里存在同名类定义。一旦发现，立即删除该文件——TP6+禁止直接覆盖核心类，必须用Facade或中间件扩展。
方法二：钩子注册重复
多个插件在app/common.php或自身service.php中调用Hook::listen('app_init')，但未加唯一标识。打开各插件的service.php，检查return [ 'app_init' => [...] ]结构，若两个插件都往app_init塞了同名函数（如checkLicense），就会覆盖执行。解决办法：给函数名加插件前缀，或改用闭包方式注册。
方法三：数据库表/字段名硬编码冲突
插件安装脚本常执行CREATE TABLE IF NOT EXISTS plugin_config，但未加项目前缀。若你项目数据库前缀是tp_，而插件写死plugin_config，就会在tp_plugin_config不存在时创建裸表，后续查询却带前缀，直接报Table 'db.tp_plugin_config' doesn't exist。检查插件的install.php，把所有plugin_替换成config('database.prefix') . 'plugin_'。
第四步：二分法验证多插件共存问题
第一步：列出当前启用的所有插件，记下名称清单。
第二步：禁用一半插件（例如前3个），测试是否正常。若仍异常，问题在剩余启用的那半里；若恢复正常，问题就在刚禁用的那半里。
第三步：对有问题的插件集合再次对半拆分，重复测试。通常3轮内即可缩到1～2个插件。
注意：【每次测试前必须清空runtime/cache/，否则路由/配置缓存会掩盖真实状态】。
找到冲突组合后，不要急于卸载，先检查它们的composer.json依赖项——常见情况是A插件require topthink/think-queue:v3.0，B插件require v2.5，Composer自动降级导致队列驱动失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
