Laravel Log门面写入NULL二进制数据至laravel.log而非正常日志

先确认日志来源是不是Laravel本身 #

• 临时注释掉所有业务里调用Log门面的代码，重启supervisord进程，看laravel.log还会不会写NULL数据。要是还写，说明不是Laravel日志组件的锅，大概率是supervisord把进程的stdout/stderr输出重定向到了这个日志文件，而进程本身输出了NULL二进制内容。
• 查supervisord配置里的stdout_logfile和stderr_logfile，要是指向了laravel.log，改成单独的进程日志文件，别和应用日志混在一起。

检查日志组件有没有被篡改或自定义 #

• 看项目里有没有自定义的日志驱动/处理器：打开app/Providers/AppServiceProvider.php或者其他服务提供者，找有没有Log::extend()的调用，或者有没有重写Log门面的方法。
• 重置Laravel日志组件：执行composer update illuminate/log重新装一遍日志组件，排除组件文件被改坏的可能。
• 就算注释了config/logging.php的所有通道，Laravel会用默认的stack通道（包含single驱动），可以直接试Log::channel('single')->info('test')，看能不能正常输出。

排查第三方包的干扰 #

• 用composer remove暂时删掉最近装的第三方包，尤其是日志、监控类的，一个个排除是不是某个包搞的鬼。
• 看vendor/composer/installed.json里的已安装包列表，重点盯带log、logger关键词的包。

验证二进制NULL数据的细节 #

• 用命令行看日志的二进制内容：执行xxd laravel.log | head -20，看NULL对应的十六进制值（一般是00），确认是纯NULL字节还是其他异常数据。
• 如果是纯NULL字节，可能是代码里有错误的写入操作，比如fwrite($logFile, null)这种写法。

内容的提问来源于stack exchange，提问作者Drew Gallagher