Laravel日志默认位于storage/logs目录，但实际路径取决于logging.php中配置的驱动（如single生成laravel.log，daily生成laravel-YYYY-MM-DD.log），且需确保Web服务器用户（如nginx）对storage/logs及其父目录有写权限，并排除SELinux、日志级别过高或挂载限制等干扰因素。
部署后的 Laravel 日志文件默认就在 storage/logs 目录下，但具体路径、可见性、权限和轮转行为会因部署环境（尤其是 Linux + Nginx/Apache + CentOS）而变化——不是所有情况都能直接 cat storage/logs/laravel.log 就看到内容。
确认日志实际写入位置和驱动类型
Laravel 不一定写到 laravel.log。先看配置：
-
config/logging.php中的默认 channel 是stack，它通常组合多个子 channel；真正落地的往往是single或daily - 检查
'single' => ['driver' => 'single', 'path' => storage_path('logs/laravel.log')]—— 这才是物理路径来源 - 如果是
'daily'驱动，文件名会是laravel-2026-08-31.log这类，ls -l storage/logs/才能发现真实文件 - 某些部署启用了
syslog或errorlog驱动，日志根本不会落在storage/logs，而是进/var/log/messages或 PHP 错误日志（查php --ini和phpinfo()中的error_log值）
为什么 ls storage/logs 看不到文件，或 tail -f 没输出
常见原因不是代码没打日志，而是权限或 SELinux 拦截：
- Web 服务器用户（如
nginx或apache）必须对storage/logs有写权限：chown -R nginx:nginx storage/logs（CentOS），且目录权限至少为755，文件为644 - SELinux 启用时，
storage/logs默认 context 可能不允许 httpd_t 写入：运行ls -Z storage/logs，若非httpd_log_t，需执行semanage fcontext -a -t httpd_log_t "/path/to/your/project/storage/logs(/.*)?"+restorecon -Rv storage/logs - 日志级别被设太高：检查
.env中LOG_LEVEL=error，导致info级日志全被过滤；临时改成debug测试 - 应用在 CLI 模式（如
php artisan）下打的日志，可能走的是另一套 handler（比如stderr），不落盘
快速定位当前生效的日志文件（Linux + CentOS 场景）
别猜路径，用命令直接验证：
- 查进程实际使用的日志路径：
lsof -u nginx | grep log（看 nginx worker 打开的 log 文件句柄） - 强制触发一条日志并观察：
php artisan tinker→Log::warning('test-deploy-' . now()->timestamp);，然后立刻ls -lt storage/logs/看哪个文件时间戳更新 - 如果用
daily驱动但没生成当天文件，可能是时区问题：Laravel 用date_default_timezone_set()，确保config/app.php的'timezone'和服务器timedatectl status一致 - 检查
storage/logs是否被挂载为 noexec 或 nodev（容器或特殊磁盘策略下），mount | grep storage可确认
最常被忽略的一点：Laravel 日志写入依赖于 storage 目录整体可写，而不仅是 logs 子目录；一旦 storage/framework/cache 或 storage/framework/views 权限异常，整个日志系统可能静默失败——不要只盯 logs。
