php容器日志默认不轮转，位置分web服务器（/var/log/apache2/、/var/log/nginx/、/var/log/php8.2-fpm.log）和应用层（如laravel的storage/logs/laravel.log）；直接exec删除不安全，应使用logrotate或服务信号重开日志；推荐禁用访问日志、将错误日志输出到stderr并配合docker日志驱动限制大小；挂载卷中的应用日志需宿主机或应用自身（如log_days）定期清理。
PHP容器里日志文件通常在哪
绝大多数 PHP 容器（如官方 php:8.2-apache、php:8.2-fpm 或基于它的 Laravel/Nginx 镜像）默认不会自动轮转或清理日志。日志位置取决于 Web 服务器和应用配置：
-
/var/log/apache2/（Apache 容器，含error.log、access.log） -
/var/log/nginx/（Nginx + PHP-FPM 容器，含error.log、access.log） -
/var/log/php8.2-fpm.log或/proc/1/fd/2（FPM 错误日志，常被重定向到 stderr） - 应用层日志：Laravel 的
storage/logs/laravel.log，Symfony 的var/log/prod.log等 —— 这些在容器内是挂载卷里的文件，不随容器删除而消失
直接进容器删 log 文件安全吗
不推荐直接 exec 进去用 rm 或 truncate，尤其对正在写的日志：
-
rm /var/log/nginx/access.log可能导致 Nginx 继续往已删除的 inode 写数据，磁盘空间不释放（直到进程重启） -
echo "" > /var/log/nginx/error.log会清空但保持文件句柄，多数服务能继续写，但部分 FPM 配置可能因权限/SELinux 拒绝重写 - 更稳妥的是用
logrotate或发信号触发服务自身 reload/ reopen 日志（如nginx -s reopen、kill -USR1 $(cat /var/run/php/php8.2-fpm.pid)）
docker run 时怎么避免日志堆积
从源头控制比事后清理更可靠。关键不是“清”，而是“不存”或“自动裁剪”：
- 禁用 Web 服务器访问日志：
– Apache：在000-default.conf中把CustomLog改成CustomLog /dev/null combined
– Nginx：在server块中加access_log off; - 让 PHP-FPM 错误日志输出到 stderr：
确保php-fpm.conf有error_log = /proc/self/fd/2，这样 Docker 会接管并可被docker logs捕获，不落地为文件 - 用 Docker 日志驱动限制大小：
docker run --log-driver=local --log-opt max-size=10m --log-opt max-file=3 ...，这管的是stdout/stderr，不是容器内文件日志
挂载卷里的应用日志怎么定期清理
比如 storage/logs/ 被 -v ./logs:/app/storage/logs 挂载后，容器删不了宿主机文件。得靠外部机制：
立即学习“PHP免费学习笔记（深入）”；
- 在宿主机用
find /path/to/logs -name "*.log" -mtime +7 -delete定期清理旧文件 - Laravel 用户可配
LOG_DAYS=7环境变量，它会让daily日志通道自动删除超期文件（需确保php artisan schedule:run在容器内运行） - 别用
docker exec -it php-app sh -c "rm -f storage/logs/*.log"—— 如果挂载的是目录而非绑定文件，这条命令实际删的是宿主机上的文件，且没做时间判断，容易误删
