ThinkPHP底层Bug常表现为页面空白、SQL异常等，因错误在框架加载早期被拦截；需在public/index.php顶部强制开启调试、清除runtime、禁用Nginx错误拦截，并通过set_exception_handler和Db::listen等手段暴露原始错误供AI定位。
ThinkPHP底层框架Bug往往不报错、不写日志、不抛异常，而是表现为页面空白、SQL执行异常、路由失效或中间件静默跳过——这类问题靠“看错误提示”根本找不到根因。AI能帮你快速定位，但前提是先让框架把真实信息“吐出来”，而不是被层层拦截。
让AI看得见：强制暴露原始错误
多数底层Bug卡在框架加载早期（如服务提供者注册、配置解析、自动加载器初始化），此时自定义异常处理器还没挂载，AI也无从下手。必须绕过框架，直连PHP底层：
- 在入口文件 public/index.php 最顶部（
<?php后第一行）插入两行：
ini_set('display_errors', '1'); error_reporting(E_ALL);
- 删掉整个 runtime/ 目录（含子目录和隐藏缓存文件），避免旧配置干扰
- 检查 Nginx 配置中是否有
fastcgi_intercept_errors on;—— 必须设为off，否则错误页被Nginx直接截成500 - CLI命令（如
php think route:list）需加-v参数才能显示完整堆栈，否则静默失败
让AI抓得住：捕获被吞掉的致命点
真正难查的Bug常藏在中间件、事件监听器、闭包回调里——它们用 try/catch 捕获异常却不重抛，或触发 Hook::listen() 时发生致命错误，导致流程中断却无痕迹：
- 在
app/exception/Handle.php的render()方法开头加一行：Log::error('Raw exception: '.$e->getMessage(), ['trace' => $e->getTraceAsString()]); - 在
app/AppServiceProviders.php或bootstrap/app.php中，于App::init()后立即注册全局钩子：set_exception_handler(function($e){ error_log('[FATAL] '.$e->getMessage().' in '.$e->getFile().':'.$e->getLine()); }); - 对可疑的中间件或事件回调，手动加
debug_backtrace(0, 5)打点，确认执行是否真的走到那里
让AI分得清：区分是框架Bug还是环境陷阱
很多“框架Bug”其实是权限、SELinux、OPcache或Docker挂载导致的假象：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -l public/index.php检查语法，排除Parse error类底层失败 - 用
strace -e trace=openat,open,write -p $(pgrep php-fpm)（需root）观察PHP是否反复尝试打开不存在的类文件或配置 - 检查
runtime/log/目录权限：ls -ld runtime/log，确保Web进程用户（如www-data）有写权；Docker部署需确认runtime目录是否正确挂载且uid/gid匹配 - 临时禁用OPcache：
opcache.enable=0（php.ini），再重启PHP-FPM，排除缓存污染导致的类加载错乱
让AI用得准：SQL与数据库层的精准还原
数据库相关Bug（如字段不存在、表引擎报错28、时间类型转换失败）最容易误导判断，因为 Db::getLastSql() 返回的是“模拟SQL”，不是真实执行语句：
- 改用
Db::listen()获取真实执行SQL：Db::listen(function($sql, $time, $explain) { dump($sql); }); - 开启SQL日志：确保
database.php中'log_sql' => true（TP5.x）或'trace' => true（TP6+），且runtime/log/可写 - 遇到
SQLSTATE[HY000]: General error: 1030 Got error 28 from storage engine这类报错，不是代码问题，是磁盘空间满或临时表目录（tmpdir）不可写，查df -h和mysql -e "SHOW VARIABLES LIKE 'tmpdir';"
