thinkphp错误日志需正确配置才能准确定位异常：关闭app_debug、确保runtime/log可写、启用record_trace、设置合适log level、结构化记录异常上下文，并验证日志内容含文件行号。
ThinkPHP 文件记录错误要能快速定位异常，关键不是“记下来”，而是“记对内容、记对位置、记对时机”。开发时看到堆栈不全、线上查不到 404、日志里没有文件行号——这些问题几乎都源于配置和写法没对齐框架机制。
确保 APP_DEBUG 关闭且 runtime/log 可写
这是最常被忽略的前置条件：
- 线上环境必须设 APP_DEBUG=false（.env 中写成
APP_DEBUG=false，不能带空格或引号） - ThinkPHP 的致命错误（Fatal error、Parse error）只在
APP_DEBUG === false时才由register_shutdown_function捕获并写入日志 -
runtime/log/目录及其父目录runtime/必须对 Web 用户（如 www-data、nginx）可写：用ls -ld runtime log检查权限，推荐chmod -R 755 runtime+chown -R www-data:www-data runtime - Docker 环境需确认挂载卷 UID/GID 与容器内 Web 用户一致，否则权限失效
开启堆栈追踪并配对日志级别
默认日志不显示文件和行号？不是 bug，是没开追踪：
- 在
config/app.php中添加'record_trace' => true - 检查
config/log.php中'level'设置是否覆盖了你想记录的级别，例如：Log::warning()不会出现在'level' => ['error']的日志里 - 开发环境建议设为
'level' => ['debug', 'info', 'warning', 'error']；生产环境至少保留warning和error - 别用
type => 'trace'或type => 'test'驱动——它们不落盘，只存内存
让异常自带上下文，而不是只记“出错了”
单纯 Log::error($e->getMessage()) 无法定位问题。要在 render() 方法中结构化记录：
- 捕获异常时，统一调用
Log::error(sprintf('[%s] %s in %s:%d, trace: %s', get_class($e), $e->getMessage(), $e->getFile(), $e->getLine(), $e->getTraceAsString())) - 记录请求参数：
$request->param()、$request->ip()、$request->url(true)，但注意过滤敏感字段（如 password、token） - 对 404 等 HTTP 异常，确认
config/log.php中'ignore_404' => false，且config/exception.php中'log' => true - 自定义业务异常类（如
ValidateException）应继承基类并携带$code、$errorCode、$msg，便于日志中快速归类
验证日志是否真写进去了
别只看配置，动手验证：
- 执行
php think run或访问一个会报错的接口（比如除零），然后立刻查runtime/log/下最新生成的xxxx-xx-xx.log - 日志条目格式应类似：
[2026-10-15T12:30:45+08:00][error] [62] Division by zero [/var/www/app/controller/Test.php:22] - 如果只有时间戳和级别、没有文件路径和行号，说明
record_trace没生效或APP_DEBUG仍为 true - 用
Log::getLog()可查看当前内存中尚未刷盘的日志，判断是否被拦截或丢弃
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
