说明日志系统在记录 Guzzle 废弃警告时崩溃了，掩盖了真正的问题

看到你发来的 config/logging.php，问题就更清楚了。

🔍 问题确认

这个配置文件里，deprecations 的定义是：

'deprecations' => [
    'channel' => env('LOG_DEPRECATIONS_CHANNEL', 'null'),
    'trace' => env('LOG_DEPRECATIONS_TRACE', false),
],

这里 channel 的值由 LOG_DEPRECATIONS_CHANNEL 环境变量决定，默认是 'null'。

而 channels 数组里确实有一个 'null' 通道：

'null' => [
    'driver' => 'monolog',
    'handler' => NullHandler::class,
],

所以配置本身是完整的，null 通道存在。那为什么还会报 Log [deprecations] is not defined 呢？

🎯 真正的原因

报错信息 Log [deprecations] is not defined 中的 deprecations 指的不是 deprecations 配置项，而是 Laravel 试图解析一个名为 deprecations 的日志通道。

关键线索在 .env 文件。检查你的 .env，很可能有这样一行：

LOG_DEPRECATIONS_CHANNEL=deprecations

或者某个环境配置把 LOG_DEPRECATIONS_CHANNEL 设为了 deprecations。这样一来：

1. config/logging.php 里 deprecations.channel 的值就变成了 'deprecations'。

2. Laravel 去 channels 数组里找名为 deprecations 的通道。

3. channels 数组里根本没有 deprecations 这个通道（只有 stack、single、daily、null 等）。

4. 于是抛出 Log [deprecations] is not defined。

🛠️ 修复方案

方案一（推荐）：修改 .env，让废弃警告走 null 通道

编辑 Fresns 根目录下的 .env 文件，找到 LOG_DEPRECATIONS_CHANNEL：

LOG_DEPRECATIONS_CHANNEL=null

如果 .env 里没有这一行，就手动加上。null 通道会直接丢弃这些废弃警告，不再触发日志系统崩溃。

方案二：在 channels 里显式定义一个 deprecations 通道

如果你希望保留废弃警告的记录，就在 config/logging.php 的 channels 数组里加一个：

'deprecations' => [
    'driver' => 'single',
    'path' => storage_path('logs/deprecations.log'),
    'level' => 'debug',
],

这样 LOG_DEPRECATIONS_CHANNEL=deprecations 就能找到对应通道了。

⚠️ 修改后必须做的两件事

1. 清理配置缓存（否则 .env 和 config 的修改不生效）：

   cd /www/wwwroot/www.madama.cn/fresns
   rm -f bootstrap/cache/config.php
   php artisan config:clear

2. 重启 Octane 进程（Swoole 常驻内存，不重启加载不到新配置）。

💡 补充说明

这个报错本身不会直接导致 Trying to access array offset on null，但它的发生说明日志系统在记录 Guzzle 废弃警告时崩溃了，掩盖了真正的问题。修好日志通道后，Guzzle 的 X-Fresns-Client-Platform-Id 类型警告会被正常处理，你就能看到更清晰的 API 请求错误信息，便于继续排查网站引擎的 API 连通性问题。

建议先按方案一快速修复，让日志系统恢复正常，再观察 Trying to access array offset on null 是否还存在。