4、日志输出后端：控制台输出、文件输出、网络输出（UDP/TCP）的实现与切换

日志系统搭好了，格式也定了，接下来就是往哪写的问题。

说白了，日志输出后端就是决定日志的「归宿」。我个人习惯把输出后端分成三类：控制台、文件、网络。这三类各有各的用武之地，而且在实际项目中，往往需要动态切换。

4.1 控制台输出：调试阶段的「贴身护卫」

控制台输出是最直接的。你想想看，在开发板上敲命令，日志直接刷屏，多痛快。

但这里有个坑——控制台输出是有代价的。我记得有一次在项目里，为了图方便，把所有调试日志都往串口打，结果发现帧率掉了一半。后来一查，串口波特率成了瓶颈。

注意：控制台输出适合调试阶段，量产固件里建议关闭或降级。否则日志刷屏会拖慢系统响应。

实现上其实很简单。以嵌入式C为例，我们通常用printf或者自己封装的uart_puts：

// 控制台输出后端
static void console_log_output(const char *msg, uint32_t len)
{
    // 直接往串口写
    uart_write_bytes(UART_NUM_0, (const uint8_t *)msg, len);
    // 或者用printf
    // printf("%s", msg);
}

嗯，这里要注意：控制台输出一般不做缓冲，每条日志立即发送。这样做的好处是实时性强，坏处是频繁中断会影响CPU效率。

4.2 文件输出：持久化存储的「保险箱」

文件输出就靠谱多了。日志写到SD卡、Flash或者eMMC里，掉电不丢失。我在项目中遇到过需要回查三天前日志的情况，要是没有文件输出，那真是抓瞎。

文件输出的核心是缓冲与刷写策略。你不能每来一条日志就写一次文件，那样Flash寿命扛不住。我建议的做法是：

  1. 先攒到缓冲区，比如4KB
  2. 缓冲区满了再一次性刷写到文件
  3. 或者定时刷写，比如每100ms刷一次

关键点：文件输出要考虑文件大小管理。我曾经吃过亏，日志文件写满了SD卡，导致系统无法正常录像。后来加上了日志轮转（log rotation）机制。

代码实现大致长这样：

// 文件输出后端
static FILE *log_file = NULL;
static char log_buffer[4096];
static uint32_t buffer_pos = 0;

static void file_log_output(const char *msg, uint32_t len)
{
    // 先拷贝到缓冲区
    memcpy(log_buffer + buffer_pos, msg, len);
    buffer_pos += len;

    // 缓冲区满了，刷写到文件
    if (buffer_pos >= sizeof(log_buffer) - 128) {
        fwrite(log_buffer, 1, buffer_pos, log_file);
        fflush(log_file);
        buffer_pos = 0;
    }
}
小技巧：文件命名可以用时间戳，比如 "log_20250101_120000.txt"。这样查找起来很方便。另外，记得在系统启动时检查磁盘空间，空间不足时要及时清理旧日志。

4.3 网络输出：远程调试的「千里眼」

网络输出是我个人最喜欢的方式。尤其是当设备部署在远端，你没法接串口线的时候，通过网络把日志发回来，简直不要太爽。

网络输出分两种：UDP 和 TCP。两者区别很明显：

特性 UDP TCP
可靠性 不可靠，可能丢包 可靠，保证送达
实时性 高，无重传机制 稍低，有重传和拥塞控制
资源占用 低，无连接维护 高，需要维护连接状态
适用场景 调试日志、非关键信息 关键日志、需要确认送达

为什么会这样？说白了，UDP就是「发了就不管」，适合日志量大但丢了也不心疼的场景。TCP则是「发了必须确认收到」，适合那些你必须要看到的日志。

我建议的做法是：默认用UDP，关键错误用TCP。这样既保证了效率，又兼顾了可靠性。

UDP实现的代码示例：

// UDP输出后端
static int udp_sock = -1;
static struct sockaddr_in dest_addr;

static void udp_log_output(const char *msg, uint32_t len)
{
    if (udp_sock < 0) return;
    sendto(udp_sock, msg, len, 0,
           (struct sockaddr *)&dest_addr, sizeof(dest_addr));
}

TCP实现的代码示例：

// TCP输出后端
static int tcp_sock = -1;

static void tcp_log_output(const char *msg, uint32_t len)
{
    if (tcp_sock < 0) return;
    // TCP需要处理断线重连
    int ret = send(tcp_sock, msg, len, 0);
    if (ret <= 0) {
        // 连接断开，尝试重连
        tcp_reconnect();
    }
}
注意：网络输出要考虑安全性。如果日志里包含敏感信息（比如WiFi密码），建议加密传输。另外，UDP有MTU限制，单条日志不要超过1472字节，否则会被分片。

4.4 输出后端的动态切换

光有这些后端还不够，关键是怎么灵活切换。你想想看，调试阶段用控制台，部署后用文件，远程维护时用网络。总不能每次改代码重新编译吧？

我习惯用函数指针数组来实现：

// 定义输出后端类型
typedef enum {
    LOG_OUTPUT_CONSOLE = 0,
    LOG_OUTPUT_FILE,
    LOG_OUTPUT_UDP,
    LOG_OUTPUT_TCP,
    LOG_OUTPUT_MAX
} log_output_type_t;

// 输出后端函数指针
typedef void (*log_output_func_t)(const char *msg, uint32_t len);

static log_output_func_t output_funcs[LOG_OUTPUT_MAX] = {
    console_log_output,
    file_log_output,
    udp_log_output,
    tcp_log_output
};

// 当前选中的输出后端
static log_output_type_t current_output = LOG_OUTPUT_CONSOLE;

// 日志输出入口
void log_output(const char *msg, uint32_t len)
{
    if (current_output < LOG_OUTPUT_MAX && output_funcs[current_output]) {
        output_funcs[current_output](msg, len);
    }
}

// 运行时切换输出后端
void log_set_output(log_output_type_t type)
{
    if (type < LOG_OUTPUT_MAX) {
        current_output = type;
    }
}

这样设计的好处是：

  • 新增后端只需要加一个函数和一个枚举值
  • 运行时通过命令行或配置文件就能切换
  • 甚至可以同时输出到多个后端（用位掩码实现）

我的经验：在实际项目中，我通常让系统启动时默认输出到控制台，等网络就绪后自动切换到UDP输出。如果检测到SD卡插入，再切换到文件输出。整个过程对用户透明，日志一条都不会丢。

嗯，最后提一句：输出后端的选择没有银弹。你得根据项目实际情况来定。比如低功耗设备就别开网络输出，存储受限的设备就别开文件输出。灵活运用，才是王道。

← 上一章 📖 返回目录 下一章 →