daily驱动必须设'lock'=>false防文件锁争用，'permission'=>0664减chmod开销，formatter中禁用Request::ip()等动态调用，加'max_files'=>30防单文件过大。
直接配错 config/logging.php 里的 daily 驱动参数，会导致日志写入变慢、并发下文件锁争用、甚至部分请求卡住 —— 这不是小概率事件，而是高并发 Laravel 应用上线后最常见的日志性能故障点。
daily 驱动必须关掉 lock 才能扛住并发
默认 Laravel 的 daily 日志驱动会启用 lock => true，每次写日志都对文件加独占锁。50+ QPS 场景下，flock() 就成瓶颈，strace 能看到大量 F_SETLK 等待。
- 务必在
config/logging.php对应通道里显式设为'lock' => false - 关锁后，多进程写同一文件可能造成日志行交错（如两行合并成一行），但只要不依赖单行原子性（比如日志分析脚本不靠行号定位），这是可接受的权衡
- 若业务强依赖日志顺序，改用
stack+single驱动配合syslog或papertrail等外部服务，别硬扛文件锁
permission 设错会让日志写入变慢
Linux 下文件权限位每变更一次，内核都要走一遍 ACL 检查路径。Laravel 默认 'permission' => 0644 是安全但低效的，尤其当 storage/logs/ 目录属主和 Web 进程 UID 不一致时，每次写日志都会触发 chmod() 调用。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 生产环境统一设为
'permission' => 0664，并确保storage/logs/目录属组可写（如chgrp www-data storage/logs） - 如果用的是容器部署，直接在 Dockerfile 里
RUN chmod -R g+w storage/logs，避免运行时反复 chmod - 绝对不要设
0777，这会触发 SELinux/AppArmor 额外检查，反而更慢
formatter 里别调用 Request::ip() 这类动态方法
自定义 Formatter 类里，每条日志都执行 Request::ip() 或 Request::fullUrl()，等于在日志路径上塞了个数据库查询级开销 —— 它要重建整个请求上下文，哪怕只是拿个 IP。
- IP 和 URL 这类字段，应在中间件里提前提取并存到
$request->attributes，formatter 只读取已缓存值 - 时间格式用
'Y-m-d H:i:s.v'而非'c'，后者触发额外时区计算 - hostname、app name 这种静态值，一定要用
static属性缓存，别每次 new 实例都gethostname()
大日志文件轮转别只靠 days，得加 max_files
'days' => 14 看似合理，但某天流量突增导致单日日志超 2GB，storage/logs/laravel-2026-04-18.log 就会变成磁盘 I/O 热点，tail -f 查日志、LogViewer 加载都卡顿。
- 在
daily配置里补上'max_files' => 30（最多保留 30 个日志文件） - 同时用
'rotate' => true（有些旧版 Laravel 需手动开启）确保按大小轮转生效 - 真正关键的是：用
logrotate外挂接管，比 PHP 内部轮转更稳，且支持copytruncate避免服务中断
最常被忽略的其实是 formatter 里那行 Request::ip() —— 它不报错、不抛异常，但把日志延迟从 0.2ms 拉到 8ms，而你查监控只会看到「整体响应慢」，根本想不到是日志组件在拖后腿。
