第三方组件日志路径不固定，需通过配置文件、代码调用或grep查找确认，清理前应停服务或清空文件而非直接删除，优先使用组件内置轮转机制。
第三方组件日志路径通常不在 logs/ 下，先确认真实位置
PHP 项目里所谓“第三方组件日志”，比如 monolog、guzzlehttp/guzzle、laravel/framework 或 symfony/http-client，它们默认**不自动写日志**，是否产生日志、写到哪，完全取决于你代码里怎么配置。常见误区是直接去删 logs/ 目录，结果发现日志还在涨——因为实际路径可能是：storage/logs/（Laravel）、var/log/（Symfony）、/tmp/app-*.log（自定义 Monolog Handler），甚至写进数据库或 syslog。
- 查入口文件或配置文件（如
config/logging.php、phpunit.xml、.env）中是否有LOG_CHANNEL、LOG_PATH、handler等关键词 - 搜索项目中
Logger::、Log::、new StreamHandler(的调用，看构造参数传了什么路径 - 临时加一行
error_log((new MonologHandlerStreamHandler('test.log'))->getFilename());快速验证路径生成逻辑
用 find + grep 定位日志文件（Linux/macOS）
如果不确定日志在哪，又不想翻代码，可以直接在终端里搜。第三方组件日志往往带特征名（如 guzzle、monolog、http_client）或格式（含时间戳+ERROR/INFO）：
-
find . -name "*.log" -type f -size +1M | xargs grep -l "HTTP.*500|GuzzleHttp\Exception"—— 找大日志里含 Guzzle 错误的文件 -
find /var/log -name "*php*" -mtime -7 2>/dev/null—— 查系统级 PHP 相关日志（如 php-fpm slow log） - 注意：有些日志是轮转的，如
app.log.1.gz、app.log.2024-05-01，要一并纳入清理范围
安全清理前必须停服务或锁文件
直接 rm -f *.log 很危险——如果 PHP 进程正往里写，可能触发 Text file busy 错误，或导致日志内容错乱、丢失最后几行。尤其 fopen(..., 'a') 模式下，文件句柄没关，删了只是 unlink，磁盘空间不会立刻释放。
