laravel日志核心在于配置而非调用，关键在config/logging.php与.env中log_channel对齐，通道驱动（如daily/single）、级别过滤、stack组合行为及目录权限等配置不当，易致丢日志、磁盘爆满或审计失效。
直接说结论：Laravel 日志不是“怎么记录”而是“怎么配好再记录”，默认配置能用，但不配好就容易在生产环境丢关键信息、撑爆磁盘或漏掉审计线索。
Log::info() 这类调用本身没毛病，问题出在底层通道没对齐场景——比如用 single 驱动跑生产，一个月后 laravel.log 超 2GB；又或者 LOG_LEVEL=debug 没关，敏感参数全进日志。
config/logging.php 里改什么才真正起作用
config/logging.php 是日志行为的总开关，但只改它还不够，必须和 .env 里的 LOG_CHANNEL 对齐。常见误操作是只改配置数组却忘了改环境变量，结果代码里写 Log::channel('daily')，实际还是走默认 stack。
-
'default' => env('LOG_CHANNEL', 'stack')这行决定所有未显式指定通道的Log::xxx()走哪 -
'channels'下每个子项（如'daily'）的'level'控制该通道最低记录级别，不是全局开关 -
'days' => 14这种参数只对daily驱动生效，single驱动完全忽略 - 如果用了
stack通道，它的'channels'数组里任意一个驱动写入失败（比如 Slack Webhook 超时），默认会静默跳过，需设'ignore_exceptions' => false才抛错
Log::channel() 显式调用时的坑
显式指定通道看似可控，但容易忽略两个现实约束：-
Log::channel('audit')->info()中的'audit'必须在config/logging.php的'channels'里真实存在，否则 Laravel 会 fallback 到default通道且不报错 - 自定义通道（如审计日志）若用
'driver' => 'single'，路径'path' => storage_path('logs/audit.log')对应目录必须可写，否则日志直接消失，连错误都不记 - 多个通道组合时（如
stack包含daily和slack），Log::channel('stack')->error()会同步触发两者，但 Slack 只收error及以上，daily却按自己level过滤，可能 Slack 收到了，文件里却没有
日志级别设置不当的真实后果
LOG_LEVEL 看似只是个字符串，但它直接影响性能和安全：
- 开发环境设
LOG_LEVEL=debug没问题，但若.env里漏改，生产环境也会记录 Eloquent 查询绑定参数，密码明文可能出现在bindings数组里 -
error级别不记录DB::transaction()内部异常堆栈，只记顶层report()抛出的内容，事务上下文丢失 -
critical及以上级别才会触发syslog驱动的LOG_CRIT标志，Linuxrsyslog配置中若只抓crit，低级别日志就进不了集中式日志系统
真正难的是让日志既够用又不泛滥——比如用户操作日志要进数据库表，但不能拖慢主流程；SQL 查询日志只在调试时开，关不掉就成性能黑洞；异常堆栈要带 request_id，但这个 ID 得从中间件注入 Monolog，不是 Log::error() 传个参数就能自动带上。
