企业官网建设流程全解析

1. 串口数据采集这件事，远比想象中琐碎

串口通信在工业控制、传感器采集、嵌入式调试这些场景里几乎是绕不开的基础能力。很多人第一次在Linux下接串口设备，以为打开/dev/ttyUSB0读数据就完事了，结果上手才发现：数据断帧、乱码、丢包、权限报错、拔插之后设备名变了、程序跑着跑着CPU飙到100%……这些问题一个接一个。标题里说的"读取、处理、保存"三个动作，看起来简单，实际上每一个都有不少门道。

这篇文章面向的是需要在Linux环境下做串口数据采集的开发者，不管你是刚接触串口的新手，还是已经写过几版采集程序但总觉得不够稳的老手，都能从中找到可以直接用的东西。我会从设备识别、串口参数配置、数据读取策略、协议解析、落盘存储、异常处理这几个维度，把整个链路拆开讲清楚，并且给出可以直接编译运行的C代码示例。选C是因为串口采集通常跑在资源受限的嵌入式Linux或者工控机上，C的可控性最好，当然Python方案我也会提一下适用场景。

核心关键词就三个：串口读取、数据处理、数据保存。但要把这三个词落地，涉及的知识面其实挺宽的——termios配置、非阻塞IO、select/poll多路复用、环形缓冲区、帧同步、文件IO缓冲策略、日志轮转等等。下面我按实际开发中会遇到的顺序，一层一层往下讲。

2. 先搞清楚你面对的是哪个串口设备

2.1 设备节点是怎么冒出来的

Linux下串口设备通常以/dev/ttyS*（板载串口）、/dev/ttyUSB*（USB转串口）、/dev/ttyACM*（USB CDC设备）的形式出现。当你插上一个CH340、CP2102或者FT232芯片的USB转串口模块，内核的usbserial驱动会加载，然后在/dev下创建对应的设备节点。用dmesg | tail就能看到内核打印出来的信息，比如识别到ch341-uart转换器， attached to ttyUSB0。

这里第一个坑就来了：设备名不固定。你今天插上模块是ttyUSB0，明天换个USB口可能就变成ttyUSB1，同时插两个模块更是分不清谁是谁。如果程序里硬编码/dev/ttyUSB0，换个环境就跑不起来。

解决办法有两个方向。一是用udev规则根据设备的VID/PID或者序列号创建固定名称的符号链接，比如在/etc/udev/rules.d/下写一条规则，把特定厂商的串口设备映射成/dev/sensor_a这样的固定名字。二是程序启动时扫描/dev/serial/by-id/目录，这个目录下的链接名包含了设备序列号，天然唯一。我一般推荐第二种，因为不需要动系统配置，程序自己就能搞定。

# 查看串口设备的详细信息 ls -l /dev/serial/by-id/ # 输出示例： # usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB0

2.2 权限问题：为什么open总是返回Permission denied

普通用户默认没有权限访问/dev/ttyUSB*，因为设备节点的属主是root，属组是dialout。你有两个选择：把当前用户加入dialout组（sudo usermod -aG dialout $USER，然后重新登录生效），或者用sudo跑程序。前者是正道，后者在开发阶段图省事可以用，但生产环境绝对不要用root跑采集程序，一旦程序有漏洞，后果不堪设想。

还有一个容易被忽略的点：串口被占用。如果有一个进程已经打开了这个串口，你再open会返回EBUSY。排查方法是fuser /dev/ttyUSB0或者lsof | grep ttyUSB，看看是谁占着。有时候是上次的程序没退干净，有时候是ModemManager这个系统服务在自动探测串口设备，它会短暂打开串口发AT指令，导致你的程序打不开。如果确认不需要ModemManager管理你的设备，可以把它禁用掉，或者用udev规则让ModemManager忽略特定设备。

2.3 串口参数：不只是波特率那么简单

打开串口之后，必须用termios结构体配置通信参数。很多人只知道设波特率，其实数据位、停止位、校验位、流控每一个都可能出问题。

配置的核心代码大概长这样：

#include <termios.h> #include <fcntl.h> #include <unistd.h> int open_serial(const char *dev, int baud) { int fd = open(dev, O_RDWR | O_NOCTTY | O_NONBLOCK); if (fd < 0) { perror("open serial"); return -1; } struct termios tty; if (tcgetattr(fd, &tty) != 0) { perror("tcgetattr"); close(fd); return -1; } cfsetospeed(&tty, baud); cfsetispeed(&tty, baud); tty.c_cflag |= (CLOCAL | CREAD); // 忽略调制解调器控制线，启用接收 tty.c_cflag &= ~CSIZE; tty.c_cflag |= CS8; // 8位数据位 tty.c_cflag &= ~PARENB; // 无校验 tty.c_cflag &= ~CSTOPB; // 1位停止位 tty.c_cflag &= ~CRTSCTS; // 无硬件流控 tty.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); // 原始模式 tty.c_iflag &= ~(IXON | IXOFF | IXANY); // 关闭软件流控 tty.c_iflag &= ~(INLCR | ICRNL | IGNCR); // 不做换行转换 tty.c_oflag &= ~OPOST; // 原始输出 tty.c_cc[VMIN] = 0; // 非阻塞读 tty.c_cc[VTIME] = 10; // 读超时1秒（单位是0.1秒） if (tcsetattr(fd, TCSANOW, &tty) != 0) { perror("tcsetattr"); close(fd); return -1; } tcflush(fd, TCIOFLUSH); // 清空收发缓冲区 return fd; }

这里有几个细节值得展开说。O_NOCTTY是告诉内核这个串口不要成为控制终端，否则程序可能会收到SIGINT之类的信号。O_NONBLOCK配合VMIN=0和VTIME实现超时读，这样read不会永久阻塞。tcflush在打开后清一次缓冲区很重要，因为串口里可能残留着上次通信的垃圾数据。

注意：VMIN和VTIME的组合行为容易搞混。VMIN=0, VTIME>0表示read最多等VTIME个0.1秒，有数据就返回数据，没数据就返回0。VMIN>0, VTIME=0表示read至少等到VMIN个字节才返回，否则一直阻塞。VMIN>0, VTIME>0表示第一个字节到达后开始计时，超时或凑够VMIN字节就返回。实际采集场景我一般用第一种，配合select做超时控制。

3. 读数据的方式选不对，后面全是坑

3.1 阻塞读、非阻塞读、多路复用怎么选

串口读取有三种基本模式。阻塞读最简单，read没数据就卡在那里，但问题是程序没法同时干别的事，也没法优雅退出。非阻塞读配合轮询，CPU空转浪费资源。多路复用（select/poll/epoll）是实际项目里最常用的，既能等数据，又能设超时，还能同时监听多个文件描述符。

我个人的选择是：单串口采集用poll就够了，代码比select清爽，没有FD_SETSIZE的限制。如果要同时采集多个串口，epoll在大量描述符时性能更好，但串口数量一般不会太多，poll完全够用。

#include <poll.h> int read_with_timeout(int fd, unsigned char *buf, int maxlen, int timeout_ms) { struct pollfd pfd; pfd.fd = fd; pfd.events = POLLIN; int ret = poll(&pfd, 1, timeout_ms); if (ret < 0) { perror("poll"); return -1; } if (ret == 0) { return 0; // 超时，无数据 } if (pfd.revents & POLLIN) { return read(fd, buf, maxlen); } return -1; }

3.2 数据断帧：为什么你收到的数据总是缺胳膊少腿

串口是字节流，没有消息边界的概念。对方设备发一帧20字节的数据，你的read可能第一次返回8字节，第二次返回12字节，也可能两次数据粘在一起返回30字节。这不是bug，是串口通信的本质。必须自己实现帧同步逻辑。

常见的帧格式有两种：定长帧和变长帧。定长帧好办，攒够N字节就处理。变长帧通常有帧头、长度字段、数据区、校验字段，比如0xAA 0x55 | len | data... | crc。解析的时候需要一个状态机，逐字节扫描，找到帧头后根据长度字段确定整帧长度，凑齐后校验，校验通过才交给业务层。

typedef enum { STATE_IDLE, STATE_HEADER1, STATE_HEADER2, STATE_LENGTH, STATE_PAYLOAD, STATE_CHECKSUM } parse_state_t; typedef struct { parse_state_t state; unsigned char buf[512]; int index; int expected_len; } frame_parser_t; void parser_init(frame_parser_t *p) { p->state = STATE_IDLE; p->index = 0; p->expected_len = 0; } // 返回1表示解析出一帧完整数据，0表示还在解析中 int parser_feed(frame_parser_t *p, unsigned char byte) { switch (p->state) { case STATE_IDLE: if (byte == 0xAA) { p->buf[0] = byte; p->index = 1; p->state = STATE_HEADER2; } break; case STATE_HEADER2: if (byte == 0x55) { p->buf[1] = byte; p->index = 2; p->state = STATE_LENGTH; } else { p->state = STATE_IDLE; } break; case STATE_LENGTH: p->buf[2] = byte; p->expected_len = byte + 4; // 帧头2 + 长度1 + 数据len + 校验1 p->index = 3; p->state = STATE_PAYLOAD; break; case STATE_PAYLOAD: p->buf[p->index++] = byte; if (p->index >= p->expected_len - 1) { p->state = STATE_CHECKSUM; } break; case STATE_CHECKSUM: p->buf[p->index++] = byte; // 这里做校验，假设是简单的累加和 { unsigned char sum = 0; for (int i = 0; i < p->index - 1; i++) { sum += p->buf[i]; } if (sum == byte) { p->state = STATE_IDLE; return 1; // 完整帧 } } p->state = STATE_IDLE; break; } return 0; }

这个状态机的思路是逐字节驱动，每收到一个字节就推进状态。好处是不管数据怎么分片到达，解析结果都一样。实际项目中，我会把read到的数据先塞进一个环形缓冲区，然后解析器从环形缓冲区里取字节，这样读写解耦，逻辑更清晰。

3.3 环形缓冲区：串口采集的标配组件

为什么需要环形缓冲区？因为read返回的数据可能包含多帧，也可能只有半帧。如果直接在read的缓冲区上做解析，处理起来很别扭。环形缓冲区（ring buffer）提供先进先出的字节流抽象，写入端只管往里塞，读取端只管从里取，两边互不干扰。

#define RING_SIZE 4096 typedef struct { unsigned char data[RING_SIZE]; volatile int head; // 写入位置 volatile int tail; // 读取位置 } ring_buf_t; int ring_write(ring_buf_t *r, const unsigned char *src, int len) { int available = (r->tail - r->head - 1 + RING_SIZE) % RING_SIZE; if (len > available) len = available; for (int i = 0; i < len; i++) { r->data[r->head] = src[i]; r->head = (r->head + 1) % RING_SIZE; } return len; } int ring_read(ring_buf_t *r, unsigned char *dst, int len) { int used = (r->head - r->tail + RING_SIZE) % RING_SIZE; if (len > used) len = used; for (int i = 0; i < len; i++) { dst[i] = r->data[r->tail]; r->tail = (r->tail + 1) % RING_SIZE; } return len; }

如果采集线程和解析线程是两个线程，head和tail的读写需要考虑内存屏障或者用原子操作。单线程场景下用volatile就够了。这个环形缓冲区的大小要根据数据速率来定，115200波特率下每秒最多约11KB数据，4KB缓冲区大概能缓冲0.36秒，一般够用。如果解析逻辑比较重，可以适当加大。

4. 数据处理：从原始字节到可用信息

4.1 字节序和数据类型转换

串口传过来的多字节数据，字节序（大端/小端）取决于发送方设备。很多传感器用大端序（网络字节序），而x86 Linux是小端，直接memcpy到int会得到错误的值。必须手动组装：

// 大端序4字节转uint32 uint32_t be32_to_u32(const unsigned char *p) { return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) | ((uint32_t)p[2] << 8) | ((uint32_t)p[3]); } // 小端序4字节转uint32 uint32_t le32_to_u32(const unsigned char *p) { return ((uint32_t)p[3] << 24) | ((uint32_t)p[2] << 16) | ((uint32_t)p[1] << 8) | ((uint32_t)p[0]); }

浮点数的处理更麻烦，有些设备用IEEE 754格式直接传，有些用定点数。如果是IEEE 754，先按字节序组装成uint32_t，再用memcpy转成float。如果是定点数，需要知道小数位数，比如温度值放大100倍传输，收到之后除以100.0。

4.2 物理量换算与校准

原始ADC值往往需要换算成物理量。比如一个12位ADC，参考电压3.3V，那么电压值 =raw / 4095.0 * 3.3。如果是电流环4-20mA的传感器，还要做线性映射。这些换算公式通常写在设备手册里，但实际使用中往往需要现场校准——因为传感器有零漂和增益误差。

我一般会在程序里留一组校准参数，支持通过配置文件或者命令行参数调整。比如温度传感器，实测发现比标准温度计低0.5度，那就加一个偏移量。这种校准值不要硬编码在代码里，否则换个传感器就得重新编译。

4.3 数据滤波：什么时候该滤，什么时候不该滤

采集到的数据往往有噪声，常见的滤波方法有滑动平均、中值滤波、一阶低通滤波。滑动平均最简单，维护一个固定长度的队列，每次新数据进来替换最老的，输出平均值。中值滤波对脉冲噪声效果好，但需要排序，计算量稍大。一阶低通滤波适合变化缓慢的信号，公式是y = alpha * x + (1 - alpha) * y，alpha越小越平滑但响应越慢。

注意：滤波会引入延迟，对于需要快速响应的控制场景，滤波参数要谨慎选择。另外，如果原始数据本身就是要保存的，建议先保存原始值，再保存滤波值，这样后期分析时还有原始数据可用。

4.4 时间戳：别等到保存的时候才想起来

每条数据都应该带时间戳，而且时间戳应该在数据到达时就打上，而不是在保存时。因为从读取到保存之间可能有排队延迟，如果保存时才打时间戳，时间就不准了。用clock_gettime(CLOCK_MONOTONIC)获取单调递增时间，避免系统时间被NTP调整导致时间戳跳变。如果需要和真实时间对应，可以在程序启动时记录一次CLOCK_REALTIME和CLOCK_MONOTONIC的差值，之后用单调时间推算真实时间。

#include <time.h> struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); long long timestamp_ms = (long long)ts.tv_sec * 1000 + ts.tv_nsec / 1000000;

5. 数据保存：写文件也有讲究

5.1 文本格式还是二进制格式

保存格式的选择取决于后续怎么用。如果数据要给人看，或者导入Excel分析，CSV文本格式最方便。如果数据量大、写入频繁，二进制格式更省空间、写入更快。我一般会同时保存两份：一份二进制原始数据用于归档和回放，一份CSV摘要用于快速查看。

CSV格式的坑在于字段里可能有逗号或换行，需要做转义。另外浮点数格式化时要注意精度，%.6f通常够用，但如果是高精度传感器可能需要更多位数。每行末尾用\n还是\r\n取决于目标平台，Linux下用\n就行。

二进制格式建议自己定义一个简单的文件头，记录魔数、版本号、数据记录的结构体大小、采集开始时间等信息，方便以后解析。每条记录定长，这样可以用fseek快速定位到第N条记录。

5.2 缓冲策略：fflush的时机很关键

标准IO库（fopen/fwrite）默认是全缓冲的，数据先写到用户空间缓冲区，缓冲区满了才真正写到磁盘。如果程序崩溃或者断电，缓冲区里的数据就丢了。对于采集程序，这是不能接受的。

解决方案是定期fflush，比如每写100条记录或者每隔1秒调用一次fflush。更严格的做法是用O_SYNC标志打开文件，每次write都同步到磁盘，但这样性能会差很多。折中方案是用fsync定期同步，比如每10秒一次。具体间隔取决于你能容忍多少数据丢失。

FILE *fp = fopen("data.csv", "a"); // ... 写入数据 ... if (++write_count % 100 == 0) { fflush(fp); }

5.3 文件轮转：别让单个文件无限增长

长时间运行的采集程序，如果一直往一个文件里写，文件会越来越大，最后可能撑爆磁盘。必须做文件轮转。策略有两种：按大小轮转和按时间轮转。按大小就是文件超过比如100MB就关闭当前文件，新建一个带序号的文件。按时间就是每小时或每天一个文件，文件名里带日期时间。

char filename[256]; time_t now = time(NULL); struct tm *tm_info = localtime(&now); strftime(filename, sizeof(filename), "data_%Y%m%d_%H%M%S.csv", tm_info);

轮转的时候要注意：关闭旧文件前一定要fflush，确保数据落盘。另外，如果磁盘空间有限，还需要实现旧文件清理逻辑，比如只保留最近7天的数据，更早的自动删除。删除前最好确认一下文件已经成功写入，避免误删。

5.4 断电保护：采集程序必须考虑的现实问题

工控现场断电是家常便饭。如果程序正在写文件时断电，文件可能损坏，尤其是CSV这种文本格式，最后一行可能是半截的。二进制格式相对好一点，但最后一条记录也可能不完整。

我的做法是：每条记录写入前先写一个长度字段或者记录头，解析时如果发现记录头不完整或者长度不对，就丢弃最后这条不完整记录。另外，文件打开用追加模式（"a"），这样即使上次异常退出，下次启动还能接着写，不会覆盖已有数据。如果对数据完整性要求极高，可以考虑先写临时文件，定期rename成正式文件，rename是原子操作，能保证文件要么是完整的旧版本，要么是完整的新版本。

6. 完整代码框架与编译运行

6.1 主循环结构

把上面的模块串起来，主循环大概是这样：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <signal.h> #include <poll.h> #include <time.h> #include <termios.h> #include <fcntl.h> #include <unistd.h> static volatile int running = 1; void signal_handler(int sig) { (void)sig; running = 0; } int main(int argc, char *argv[]) { const char *dev = argc > 1 ? argv[1] : "/dev/ttyUSB0"; int fd = open_serial(dev, B115200); if (fd < 0) return 1; signal(SIGINT, signal_handler); signal(SIGTERM, signal_handler); ring_buf_t ring; memset(&ring, 0, sizeof(ring)); frame_parser_t parser; parser_init(&parser); FILE *fp = fopen("sensor_data.csv", "a"); if (!fp) { perror("fopen"); close(fd); return 1; } unsigned char read_buf[256]; unsigned char byte; int write_count = 0; while (running) { int n = read_with_timeout(fd, read_buf, sizeof(read_buf), 100); if (n > 0) { ring_write(&ring, read_buf, n); } // 从环形缓冲区取字节喂给解析器 while (ring_read(&ring, &byte, 1) == 1) { if (parser_feed(&parser, byte)) { // 解析出一帧完整数据 // 假设数据区从buf[3]开始，长度为expected_len-4 int data_len = parser.expected_len - 4; // 这里做业务处理，比如解析出温度值 // 然后保存 struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); long long ts_ms = (long long)ts.tv_sec * 1000 + ts.tv_nsec / 1000000; fprintf(fp, "%lld,", ts_ms); for (int i = 0; i < data_len; i++) { fprintf(fp, "%02X", parser.buf[3 + i]); } fprintf(fp, "\n"); if (++write_count % 100 == 0) { fflush(fp); } } } } fflush(fp); fclose(fp); close(fd); return 0; }

编译命令：

gcc -o serial_collector serial_collector.c -Wall -O2

运行：

./serial_collector /dev/ttyUSB0

6.2 Python方案：什么时候用，什么时候不用

如果采集频率不高（比如每秒几条数据），或者只是做原型验证，Python的pyserial库非常方便：

import serial import time import csv ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=1) with open('data.csv', 'a', newline='') as f: writer = csv.writer(f) while True: data = ser.read(ser.in_waiting or 1) if data: ts = time.monotonic() writer.writerow([ts, data.hex()]) f.flush()

Python的缺点是GIL导致多线程性能受限，高频采集时可能丢数据。另外Python进程的内存占用和启动时间也比C大。所以我的建议是：原型用Python，生产用C。如果团队全是Python背景，用Python也可以，但要注意用serial.read配合合适的超时，避免CPU空转。

6.3 调试技巧：没有硬件怎么测

开发阶段不一定手头有真实设备，可以用虚拟串口对来模拟。Linux下用socat可以创建一对互相连接的伪终端：

socat -d -d pty,raw,echo=0 pty,raw,echo=0

它会输出两个设备路径，比如/dev/pts/3和/dev/pts/4。你的程序打开其中一个，用另一个发数据，就能模拟串口通信。发数据可以用echo -e或者写个小脚本。

另一个技巧是用strace跟踪系统调用，看看read到底返回了什么，open是否成功，ioctl有没有报错。strace -e trace=read,write,open,ioctl ./serial_collector能快速定位问题。

7. 那些只有踩过才知道的坑

7.1 USB转串口的热插拔问题

USB转串口模块拔掉再插上，/dev/ttyUSB0可能变成/dev/ttyUSB1，原来的文件描述符会失效，read返回-1并且errno是ENODEV。程序必须处理这种情况：检测到ENODEV或者EIO时，关闭旧fd，重新扫描设备，尝试重新打开。如果设备名是固定的（通过udev规则），重新打开同一个路径就行。如果不是，需要重新扫描/dev/serial/by-id/。

重连逻辑要加退避，不能一失败就疯狂重试，否则CPU和日志都会爆炸。我一般用指数退避，第一次等1秒，第二次2秒，最多等30秒。

7.2 数据量太大导致磁盘写满

这个坑很隐蔽，程序跑得好好的，突然某天发现不写数据了，一查磁盘满了。除了文件轮转和旧文件清理，还应该监控磁盘剩余空间，低于阈值时告警或者暂停采集。可以用statvfs获取磁盘信息：

#include <sys/statvfs.h> struct statvfs vfs; statvfs("/data", &vfs); unsigned long free_mb = vfs.f_bavail * vfs.f_frsize / (1024 * 1024); if (free_mb < 100) { // 告警或停止写入 }

7.3 串口参数被意外修改

有些设备在上电或者复位时会发送一些控制字符，如果串口配置了ICRNL（把\r转成\n）或者IXON（软件流控），这些字符可能被解释成控制命令，导致串口行为异常。所以配置串口时一定要把所有不必要的输入处理关掉，用原始模式（raw mode）。我在代码里把c_iflag和c_lflag里能关的都关了，就是为了避免这种意外。

7.4 多线程下的资源竞争

如果采集和保存分在两个线程，共享的环形缓冲区需要加锁或者用无锁队列。加锁简单但可能影响性能，无锁队列性能好但实现复杂容易出错。我的经验是：如果采集频率在每秒几千条以内，用互斥锁完全够用，不要过早优化。真正需要无锁队列的场景，通常是每秒几十万条以上的高速采集，那种场景一般也不会用串口。

7.5 日志和数据的分离

程序运行日志（比如"打开串口成功"、"解析错误"）和数据文件要分开保存。日志用syslog或者单独的日志文件，数据用专门的数据文件。不要把日志和数据混在一个文件里，否则后期解析数据时还要过滤日志行，很麻烦。日志级别也要控制，正常运行时只记warning以上，调试时才开debug，否则日志文件增长太快。

8. 性能调优的几个实际手段

8.1 减少系统调用次数

每次read都是一次系统调用，有开销。如果数据速率很高，可以一次read尽量多的数据。VMIN和VTIME的设置会影响read的行为，配合poll使用可以在有数据时批量读取。另外，read的缓冲区不要太小，256字节到4KB之间比较合适。

8.2 文件IO的批量写入

前面提到用fprintf逐条写，每次fprintf都有格式化开销。如果性能要求高，可以自己拼字符串到缓冲区，攒够一批再write。或者用writev一次性写入多个缓冲区。对于二进制格式，直接fwrite结构体数组比逐条写快得多。

8.3 CPU占用率优化

如果发现程序CPU占用率高，先检查是不是在忙等待。poll的超时时间不要设0，设0会立即返回，变成轮询。设100ms到1s比较合理。另外，解析器逐字节处理在大数据量时可能成为瓶颈，可以优化成批量扫描帧头，找到帧头后再逐字节解析。

8.4 内存占用控制

环形缓冲区、解析缓冲区、文件写缓冲区的大小都要合理设置。嵌入式设备内存有限，不要动不动就分配几MB的缓冲区。根据实际数据速率计算所需的最小缓冲区大小，留2-3倍余量即可。

9. 从采集到可用数据的完整链路回顾

整条链路走下来，核心就三件事：稳定地读、正确地解析、可靠地存。读的时候注意设备识别、权限、参数配置、超时控制；解析的时候注意帧同步、字节序、校验、时间戳；存的时候注意格式选择、缓冲策略、文件轮转、断电保护。每一个环节都有坑，但每一个坑都有成熟的解决方案。

我在实际项目里最深的体会是：串口采集程序的健壮性，80%取决于异常处理做得好不好。正常流程谁都能写，但设备拔插、磁盘满、数据异常、程序被杀这些情况处理不好，程序就没法长期稳定运行。所以写这类程序，一定要把"出错了怎么办"想清楚，而不是只想着"正常情况怎么跑"。

另外，测试阶段一定要用真实设备跑足够长的时间，至少24小时以上，观察内存有没有泄漏、文件有没有正常轮转、时间戳有没有跳变。很多问题只有在长时间运行后才会暴露出来。如果条件允许，模拟断电、拔插串口、填满磁盘这些异常场景，验证程序的恢复能力。这些测试做完，程序才算真正可用。