thinkphp 默认不记录500错误详情是因生产环境安全策略屏蔽堆栈，需在handle.php的report()中手动调用log::record()补录getmessage()与gettraceasstring()，并添加脱敏后的请求上下文。
为什么 thinkphp 默认日志不记录 500 错误详情？
因为默认配置下，thinkphp 在生产环境（app_debug = false）会屏蔽异常堆栈，只写入极简的错误类型和请求 URL，不记录 Exception 的 getMessage()、getTraceAsString() 或上下文变量。这不是 bug，是安全策略——但代价是排查困难。
实操建议：
- 确认当前环境确实是生产模式：
env('APP_DEBUG', false)，且config/app.php中'show_error_msg' => false - 不要改
think\exception\Handle的render()方法来输出页面，那会暴露敏感信息；重点改日志写入逻辑 - 核心动作是重写
think\log\driver\File的write()行为，或在异常处理流程中主动补录
如何让 Log::record() 捕获完整异常堆栈？
Log::record() 本身不自动捕获未捕获异常，它只记录你显式调用时传入的内容。真正要抓全量 500，得在 app/exception/Handle.php 的 report() 方法里手动触发。
实操建议：
- 在
report()中判断是否为HttpException或其他业务异常，再调用Log::record($e->getTraceAsString(), 'error') - 避免直接记录
$e->__toString()，某些 PHP 版本会触发额外错误；优先用$e->getMessage() . "\n" . $e->getTraceAsString() - 加上请求上下文：如
request()->url()、input()（注意过滤密码字段）、session()->all()（谨慎，避免敏感 session 泄露）
log.level 和 log.type 怎么配才不丢关键错误？
默认 log.level = ['error'] 看似合理，但部分底层错误（如 PDO 连接失败、Redis 超时）可能以 notice 或 warning 级别抛出，被过滤掉。而 log.type = 'File' 是基础，但单文件易被覆盖或轮转丢失。
实操建议：
- 设为
'level' => ['error', 'warning', 'notice']，上线后观察日志体积，再酌情收紧 - 启用
'single' => false和'max_files' => 30，避免单个日志文件过大导致tail -f卡死或grep失效 - 若用
monolog驱动，务必检查Monolog\Handler\RotatingFileHandler的构造参数，$maxFiles是整数，不是字符串
线上日志里为什么看不到 POST 参数和用户 IP？
TP 默认日志不自动注入请求上下文，$_POST、$_SERVER['REMOTE_ADDR'] 这类信息需显式采集。而且部分中间件（如多级代理）下 request()->ip() 可能返回 127.0.0.1，实际要读 X-Forwarded-For。
实操建议：
- 在
report()中构建日志内容时，用request()->header('x-forwarded-for', request()->ip())获取真实 IP - 记录 POST 数据前做脱敏：
array_map(function($v) { return is_string($v) ? substr($v, 0, 100) : $v; }, input('post.')) - 不要在日志里记录
input('password')、input('token')等字段，哪怕只是截断——最好白名单式采集，如只记input('order_id')、input('amount')
真正难的不是写进文件，而是确保每条错误日志都带可定位的上下文、不泄露敏感数据、且在高并发下不拖垮性能。TP 的日志扩展点足够，但需要你亲手把 report()、Log::record() 和配置项串成一条可控链路。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
