webman日志配置文件在config/log.php，需修改该php数组配置handlers、level、path等参数，确保目录存在且进程有写权限，避免误改runtime/logs/下的输出文件。
Webman 的日志配置文件在哪、怎么改
Webman 的核心日志配置在 config/log.php，不是 runtime/logs/ 下的文件——后者只是输出目标。这个 PHP 数组返回值决定了日志写什么、写哪、写多少。
常见误操作是直接往 runtime/logs/ 里手动删日志或改权限，却忘了 log.php 里 'path' 指向的目录是否真实存在、Web 进程是否有写权限。比如你把 'path' => runtime_path() . '/logs/' 写成 'path' => '/var/log/webman/'，但没提前 mkdir -p /var/log/webman && chown www-data:www-data /var/log/webman，日志就静默失败。
-
'level'默认是\Monolog\Logger::INFO，E_NOTICE和E_DEPRECATED不会记录——这很合理，但如果你正排查变量未定义问题，得临时调高到DEBUG -
'file' => 'webman.log'控制单个日志文件名；如需按天切分，要换用RotatingFileHandler，不能只靠改文件名 - 多个处理器可共存：一个写文件，一个推到
syslog，一个发 Slack，全靠'handlers'数组配置
错误没进日志？先查这三处
Webman 启动后报错但 runtime/logs/webman.log 空空如也，大概率卡在这三个地方：
-
config/exception.php被误删或返回了空数组，导致support\exception\Handler没被加载，异常直接透出给 Worker，而 Worker 日志走的是runtime/logs/workerman.log（不是 webman.log） -
config/log.php中'default'键名拼错，比如写成'defalut'，框架 fallback 到无 handler 状态 - 自定义异常类（如
app\exception\BusinessException）抛出后，config/exception.php里没注册对应处理器，它就掉进默认处理器里——但默认处理器只在APP_DEBUG = true时才打详细堆栈到日志，生产环境默认静默
验证方法：在路由闭包里写 throw new \Exception('test');，看 webman.log 是否出现带 trace 的条目。没有？立刻回头检视上面三点。
Webman 性能监控数据不显示 Trace::enable() 够吗
不够。Trace::enable() 只是开总开关，真正采集请求耗时、SQL、Redis 调用等指标，依赖中间件和组件的显式集成。
- HTTP 请求耗时：必须启用
support/middleware/SessionMiddleware或自定义中间件调用Trace::start('http')和Trace::end('http')，否则只有「框架启动」时间，没有「本次请求」时间 - 数据库慢查询：仅当使用
webman/database组件且配置了'slow_query_ms' => 100，才会在日志里标记[SLOW QUERY]；原生 PDO 不触发 - Redis 命令监控：需要替换
Predis\Client为webman/redis封装类，并在config/redis.php中开启'trace' => true
最简验证法：在控制器里加 Trace::record('custom', 'hello');，然后查日志是否出现 [TRACE] custom: hello。出现，说明 Trace 基础通；不出现，说明 Trace::enable() 没生效或被后续代码覆盖。
生产环境日志敏感信息过滤怎么做
Webman 默认不脱敏 POST 数据、Header、Cookie，全量记入日志——这在支付、登录等接口上是严重风险。
- 禁止在
config/log.php的'handlers'里用LineFormatter的默认构造，必须传第四个参数true启用allowInlineLineBreaks，否则 JSON 结构化日志会被截断 - 敏感字段过滤靠
Monolog\Processor\PsrLogMessageProcessor不够，得自己写 Processor：拦截$record['context']，对$_POST、$_SERVER['HTTP_AUTHORIZATION']等键做preg_replace('/.*/', '***') - 更稳妥的做法是，在入口
public/index.php最前头加set_error_handler()和set_exception_handler()，统一处理未进 Webman 流程的致命错误（如解析失败、内存溢出），这些错误根本不会触发Trace或Log类
真正容易被忽略的点：Worker 进程崩溃日志（workerman.log）默认不经过任何 Processor，里面可能明文出现数据库密码（如果配置写在 env 里但没设 APP_ENV=production）。务必确认 config/server.php 中 'log_file' 指向受控路径，且该文件权限为 640。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
