应先确认php实际运行用户（如www-data或nginx），再用chown将其设为storage/logs所有者，而非仅改chmod；还需排查selinux、磁盘/inode空间、父目录执行权限、日志级别及配置缓存是否生效。
storage/logs 目录权限不够，chmod 改了也不生效？
直接改 chmod -R 777 storage/logs 很可能没用——因为 PHP 进程根本不是以你当前 SSH 登录的用户身份运行的。真正起作用的是 Web 服务器（如 Nginx）或 PHP-FPM 所用的运行用户（常见为 www、www-data 或 nginx），它必须对目录有写权限，而不仅仅是“数字权限看起来够”。
- 先确认 PHP 实际运行用户：
ps aux | grep php-fpm或查宝塔面板里对应 PHP 版本的“运行用户”字段 - 再看目录归属：
ls -ld storage/logs，第三列（所有者）必须和上一步的运行用户一致 - 如果所有者不对，仅改
chmod没意义，得先chown www:www storage/logs（CentOS/宝塔）或chown www-data:www-data storage/logs（Ubuntu/Debian） - 目录权限建议设为
755（drwxr-xr-x），文件权限设为644；777不解决根本问题，还埋下安全风险
为什么 chmod 755 后还是写不进日志？
权限数字只是表层，Linux 下还有更隐蔽的拦截机制。
- SELinux 可能阻止写入：执行
sestatus，若为enabled，再运行ls -Z storage/logs，确认上下文是否含httpd_sys_rw_content_t；不是就补一句chcon -R -t httpd_sys_rw_content_t storage/logs - 磁盘或 inode 耗尽：
df -h和df -i都要看，尤其小文件多的项目容易触发 inode 满（inode usage 100%） - 父目录缺执行权限（x）：
storage目录本身若无x位（比如权限是644），PHP 就无法进入logs子目录，哪怕logs自身是777
ThinkPHP / Laravel 日志不出现，但没报错？
不是权限问题，而是日志级别或驱动被静默覆盖了。
- ThinkPHP 默认只记录
error及以上级别，Log::info()或Log::debug()完全不会落盘；检查config/log.php中'level' => 'error'是否被设得太严 - Laravel 的
LOG_LEVEL=debug必须在.env里显式配置，且要执行php artisan config:clear才能生效——缓存不清理，改了也白改 - CLI 环境（如
php artisan schedule:run）默认仍往storage/logs写，但容器或 Serverless 环境里该路径常不可写，需单独配LOG_CHANNEL=stderr或挂载可写卷
权限修完，日志还是空的？先盯住这几个地方
别急着重 chmod，先快速验证底层是否真通。
- 手动测试写入：
sudo -u www touch storage/logs/test.log（把www换成你实际的运行用户），失败就说明权限/SELinux/磁盘任一环节卡住了 - 检查错误日志源头：
tail -f /var/log/php-fpm/www-error.log或 Nginx 的error_log，里面常有failed to open stream: Permission denied这类直白提示 - 确认日志驱动没被代码覆盖：搜索项目里有没有
Log::driver('xxx')或Log::useFiles(...)这类硬编码，它们会绕过配置文件
chmod 只动了其中一层，漏掉任意一层，日志就继续沉默。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
