SocketCAN 实战：Linux CAN 总线编程从字符设备到网络设备

CAN总线在汽车电子、工控设备里属于老资格的总线了，但很多刚转过来的开发者第一反应还是去找厂商提供的字符设备驱动，打开/dev/can0然后read/write。这套做法在十几年前是主流，现在在Linux上基本已经被淘汰了——内核从2.6.25开始就把CAN控制器统一抽象成了网络设备，你操作它用的是一套和UDP socket几乎一模一样的API，也就是socket_can。这篇文章不打算复述手册上已有的函数原型，而是按我做项目的顺序讲：为什么值得换掉字符设备那套、环境到底怎么搭、代码主线怎么写、真正挂到总线上之后会在哪里翻车。

1. 从字符设备到SocketCAN：Linux下的CAN编程为什么要换思路

1.1 CAN控制器在Linux里到底是什么角色

先说结论：在SocketCAN框架下，一块CAN控制器就等于一块网卡。你去ip link show能看到它，叫can0、can1，它有MTU概念（经典CAN是16字节，CAN FD是72字节），能up能down，能被抓包工具盯上。这个抽象是内核在net/can目录下实现的，控制器驱动层（比如SPI接口的MCP2515、USB接口的那些适配器、SoC自带的FlexCAN）负责把硬件寄存器操作包装成net_device，上层统一走AF_CAN协议族。

为什么这个抽象这么关键？因为CAN的报文语义和以太网完全不同——它没有源地址，只有11位或29位的标识符；一帧最多8字节（经典CAN）或64字节（CAN FD）；总线上所有节点共享介质，靠仲裁决定谁先发。如果直接套用TCP/IP那套addr概念会很别扭，所以SocketCAN的设计是：socket地址里绑定的是接口索引，而不是某个远端地址；发送时指定的是CAN ID，接收时靠过滤器筛ID。这个思路你要先接受，后面的代码才看得顺。

1.2 字符设备驱动为什么迟早要换掉

我在一个工控项目上吃过这个亏。设备用的是某家USB转CAN适配器，厂商给了自己的驱动和一套ioctl接口，代码写得好好的。结果客户临时换了一块板子，SoC自带CAN控制器，走的是完全不同的驱动，我们整个通信层重写了一遍。这不是个例，字符设备时代每个厂商都有自己的struct can_msg、自己的ioctl编号、自己的错误码定义，上层业务代码和硬件耦合死了。

换成SocketCAN之后，同一份write(s, &frame, sizeof(frame))代码，在x86上跑USB适配器、在ARM上跑板载控制器、在开发机上跑虚拟总线，一行都不用改。你只需要在内核里把对应的驱动模块编进去或者加载进来。这个可移植性上的收益，是我认为值得花两天时间重构通信层的核心理由。

顺带提一下，SocketCAN还白送了你几样东西：select、poll、epoll这些多路复用机制可以直接用；SO_RCVTIMEO超时控制直接用；SO_TIMESTAMPNS时间戳直接打在内核收包那一刻，精度比你在用户态自己读时钟高得多（对做时序分析特别重要）。这些在字符设备方案里都得自己实现。

1.3 三种典型场景，代码其实只有一份

• 真实硬件直连：SoC或MCU侧的CAN控制器，通过设备树配置引脚和时钟，启动后出现can0。
• USB转CAN盒子：插上后加载gs_usb、peak_usb、slcan之类的模块，出现can0或slcan0。
• 虚拟总线vcan：完全没有硬件，纯内核软件模拟，用于开发阶段跑通逻辑、写单元测试。多人协作时，每个人电脑上都能起一对vcan，互相之间代码还在同一个网络命名空间里，很省事。

这三种场景的共性是：上层代码完全一致，差别只在ip link那几条配置命令。我后面会分别给出配置方法。

2. 环境准备：内核模块、can-utils与虚拟CAN总线

2.1 先确认内核里SocketCAN组件齐不齐

别急着写代码，先做体检。SocketCAN在Kconfig里是一堆开关，分别是CONFIG_CAN（协议族本身）、CONFIG_CAN_RAW（原始套接字）、CONFIG_CAN_BCM（广播管理器，周期发送用）、CONFIG_CAN_DEV（设备驱动框架），以及具体控制器驱动。查看方式：

# 有/proc/config.gz的发行版 zcat /proc/config.gz | grep -i "^CONFIG_CAN" # 常见发行版 grep -i "^CONFIG_CAN" /boot/config-$(uname -r)

如果看到=m，说明是模块，手动加载即可；如果是CONFIG_CAN_RAW=m但你加载时报"module not found"，那多半是这个内核没编。自己编内核的话，在Networking support -> CAN bus subsystem support下面按需勾选。我习惯至少勾上RAW、BCM、VCAN、CAN_GW这四个。

加载检查：

sudo modprobe can sudo modprobe can_raw sudo modprobe can_bcm sudo modprobe vcan lsmod | grep can

如果你用的是较新的内核（5.4以上），CAN相关模块通常会因为依赖关系自动被带上来，lsmod里能看到can、can_raw、can_dev。

2.2 can-utils：不装它你会多花一倍时间

can-utils是SocketCAN配套的命令行工具集，官方仓库维护。Debian/Ubuntu系直接sudo apt install can-utils，RHEL系yum install can-utils，要最新版就自己clone编译（autotools，./autogen.sh && ./configure && make）。

几个必须记住的：

cansend的报文格式要背下来：ID#数据，标准帧直接用ID，扩展帧写成8位十六进制；要发远程帧把数据段写成R。这个格式在你后面写C代码验证的时候，就是最方便的对照组——先用cansend发一帧，再用自己的程序收，能最快定位问题出在硬件侧还是代码侧。

2.3 用vcan把没有硬件的开发环境跑起来

这是我最推荐新手起步的方式，五分钟搞定：

sudo modprobe vcan sudo ip link add dev vcan0 type vcan sudo ip link set up vcan0 ip -details link show vcan0

起来之后，这个vcan0就是一个闭环的总线：往它写的数据，同网络命名空间里所有绑定了vcan0的socket都能读到，包括你自己同一个进程的两个socket（因为vcan默认开回环）。测试一下：

# 终端A candump vcan0 # 终端B cansend vcan0 123#DEADBEEF

终端A立刻能看到，说明整条链路是通的。这时候再开始写C程序，就等于把"硬件对不对"这个变量完全排除掉了。

要建多条虚拟总线做网关测试，就再ip link add dev vcan1 type vcan，重复即可。删掉用ip link del vcan0。注意vcan是内核模块级的，重启后创建的接口会消失，需要写进启动脚本。

2.4 真实CAN控制器的接口拉起流程

硬件侧的差异比较大，但配置命令基本统一：

# 经典CAN，500kbps sudo ip link set can0 type can bitrate 500000 sudo ip link set up can0 # 开启自动重启，总线出错后100ms自动恢复 sudo ip link set can0 type can bitrate 500000 restart-ms 100 # CAN FD：仲裁段500k，数据段2M sudo ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on

波特率的参数不是随便填的，内核会反算分频。位时间的构成是：位时间 = tq × (1 + tseg1 + tseg2)，其中tq = 分频值 / 控制器时钟频率。采样点位置是(1 + tseg1) / (1 + tseg1 + tseg2)。默认值内核会给你算一个，但如果对端设备比较挑（很多老设备要求采样点87.5%），你就得手动指定：

sudo ip link set can0 type can bitrate 500000 sample-point 0.875

采样点对不上的典型症状是：短总线近距离通信正常，线一长或者节点一多就开始随机丢帧、报错误帧。这个坑我在第5节展开讲。

USB转CAN的适配器，插上后dmesg | tail看有没有识别到，常见的驱动是gs_usb（搞CAN分析仪那种）、peak_usb、kvaser_usb。SPI接口的MCP2515需要在设备树里配interrupt-parent、clocks、spi-max-frequency，这块和具体板子强相关，不在本文范围内展开。

3. 代码主线：socket/bind/read/write这条线怎么走

3.1 struct sockaddr_can和can_frame是两个绕不开的结构体

先说sockaddr_can，它在linux/can.h里：

struct sockaddr_can { sa_family_t can_family; /* 固定填 AF_CAN */ int can_ifindex; /* 接口索引，由 ioctl 拿到 */ union { struct { canid_t rx_id, tx_id; } tp; /* 只有ISO-TP用得上 */ } can_addr; };

注意can_ifindex不是接口名字符串，是内核给接口分配的整数索引。拿到它的标准姿势是ioctl加SIOCGIFINDEX，也可以用glibc的if_nametoindex()，效果一样。

再看帧结构struct can_frame：

struct can_frame { canid_t can_id; /* 29位ID + 3位标志位 */ __u8 can_dlc; /* 数据长度，0~8 */ __u8 __pad; /* 填充，不要动 */ __u8 __res0; __u8 __res1; __u8 data[8] __attribute__((aligned(8))); };

can_id里高3位是标志：CAN_EFF_FLAG（0x80000000，表示扩展帧）、CAN_RTR_FLAG（0x40000000，远程帧）、CAN_ERR_FLAG（0x20000000，错误帧）。所以发扩展帧要写成0x18DAF110 | CAN_EFF_FLAG，光写ID内核会当成标准帧处理，把高11位截断——这个错误很隐蔽，因为发送不会报错，只是对方收不到。

另外提一句，新版内核（5.13之后）把can_frame改成用union了，字段名可以是len也可以是can_dlc，两者内存布局一致。你如果面向老内核（4.x、5.4 LTS），老老实实用can_dlc。

3.2 一笔一笔写清楚完整的最小可运行程序

下面这段代码我打磨过很多次，直接拿去当模板用：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <net/if.h> #include <sys/socket.h> #include <sys/ioctl.h> #include <linux/can.h> #include <linux/can/raw.h> int main(int argc, char *argv[]) { const char *ifname = (argc > 1) ? argv[1] : "vcan0"; int s; struct sockaddr_can addr; struct ifreq ifr; struct can_frame frame; int nbytes; /* 1. 创建原始CAN套接字 */ if ((s = socket(PF_CAN, SOCK_RAW, CAN_RAW)) < 0) { perror("socket"); return 1; } /* 2. 通过接口名拿索引 */ memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, ifname, IFNAMSIZ - 1); if (ioctl(s, SIOCGIFINDEX, &ifr) < 0) { perror("ioctl SIOCGIFINDEX"); close(s); return 1; } /* 3. 绑定到接口 */ memset(&addr, 0, sizeof(addr)); addr.can_family = AF_CAN; addr.can_ifindex = ifr.ifr_ifindex; if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); close(s); return 1; } /* 4. 组装并发送一帧标准帧 */ frame.can_id = 0x123; frame.can_dlc = 8; for (int i = 0; i < 8; i++) frame.data[i] = (__u8)i; nbytes = write(s, &frame, sizeof(frame)); if (nbytes != sizeof(frame)) { perror("write"); close(s); return 1; } printf("sent id=0x%03X dlc=%d\n", frame.can_id, frame.can_dlc); /* 5. 收一帧，阻塞等待 */ nbytes = read(s, &frame, sizeof(frame)); if (nbytes < 0) { perror("read"); close(s); return 1; } if (nbytes < (int)sizeof(struct can_frame)) { fprintf(stderr, "read: incomplete CAN frame\n"); close(s); return 1; } if (frame.can_id & CAN_EFF_FLAG) printf("rx ext id=0x%08X dlc=%d data=", frame.can_id & CAN_EFF_MASK, frame.can_dlc); else printf("rx std id=0x%03X dlc=%d data=", frame.can_id & CAN_SFF_MASK, frame.can_dlc); for (int i = 0; i < frame.can_dlc; i++) printf("%02X ", frame.data[i]); printf("\n"); close(s); return 0; }

编译：gcc -o can_test can_test.c，运行./can_test vcan0。在另一个终端开着candump vcan0，你会在自己发的那帧被自己收到（因为vcan开了回环），同时candump也能看到。

3.3 三个细节不说清楚你一定会中招

第一个坑：sizeof(struct can_frame)不能少。内核在write里会检查你传的长度，小于sizeof(struct can_frame)直接返回EINVAL。很多人图省事写write(s, &frame, frame.can_dlc + 8)之类的，必挂。read这边同理，缓冲区开小了会返回-ENOBUFS或者截断，判断的时候要用nbytes < sizeof(struct can_frame)来识别异常。

第二个坑：__pad、__res0、__res1这三个字节。这是CCAN历史上的对齐残留，不是保留给用户的。用memset清零整个结构体再填字段，别单独去动它们。有人喜欢用struct can_frame frame = {0};，这样是对的。

第三个坑：发送不阻塞，接收才阻塞。write返回成功只代表报文进了发送队列，不代表已经上了总线，更不代表对端收到了。CAN本身没有ACK到应用层，硬件层的ACK是链路层的应答位，只有总线上没有其他节点应答时，控制器才会报CAN_ERR_ACK。这个语义差异要习惯，别指望用返回值判断对方收没收到。

3.4 关于connect：可以让代码更短，但会牺牲灵活性

如果你只跟一个固定ID通信，可以先connect()再用send()：

addr.can_addr.tp.tx_id = 0x123; connect(s, (struct sockaddr *)&addr, sizeof(addr)); /* 之后 write(s, &frame, sizeof(frame)) 就直接发到0x123 */

而已绑定的socket上用write发送，ID是取自frame.can_id，connect设置的默认ID只在send时没有目标信息的情况下生效（实际上SocketCAN实现里做了合并）。我一般不用connect，因为一个进程往往要发多个ID，显式写can_id更好读，也能避免后来者看代码时困惑。

4. 过滤器、超时与错误帧：程序能不能扛住真实总线就看这一节

4.1 内核态过滤：把不需要的报文挡在用户态之外

总线上跑了十几路信号的时候，你的程序可能只关心其中两三个ID。如果不过滤，所有报文都会从内核复制到用户态，CPU和上下文切换的开销非常可观。SocketCAN支持在socket上挂过滤器，由内核决定要不要投递：

struct can_filter rfilter[2]; /* 只关心标准帧 0x123 */ rfilter[0].can_id = 0x123; rfilter[0].can_mask = CAN_SFF_MASK; /* 只关心扩展帧 0x18DAF110 */ rfilter[1].can_id = 0x18DAF110 | CAN_EFF_FLAG; rfilter[1].can_mask = CAN_EFF_MASK | CAN_EFF_FLAG; setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));

can_mask的语义是"哪些位参与比较"，置1的位必须匹配。这个逻辑和CAN控制器的硬件验收滤波器一致，很好理解。默认不设过滤器就是全收。

一个容易被忽略的点：多个过滤器之间默认是或的关系，命中任意一个就投递。如果你想要"与"的效果，也就是要求同时满足多个条件，那得用CAN_RAW_JOIN_FILTERS（内核4.1起支持）：

int join = 1; setsockopt(s, SOL_CAN_RAW, CAN_RAW_JOIN_FILTERS, &join, sizeof(join));

这个选项实际用途不多，我印象里只在做ID区间细分的网关逻辑时用过一次。

还有个开关值得知道：CAN_RAW_RECV_OWN_MSGS，控制自己发的报文要不要收回来。默认在某些接口类型（vcan、loopback模式）下是开的。如果你发现程序在"自问自答"死循环，十有八九是这个。想关掉：

int recv_own = 0; setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, &recv_own, sizeof(recv_own));

4.2 SO_RCVTIMEO和epoll：别让read把线程卡死

裸阻塞的read在调试时很方便，上生产就是灾难——总线十分钟没报文，你的线程就十分钟动不了，连退出信号都响应不了。两个方案，看场景选：

方案一：接收超时。适合单接口、逻辑简单的程序。

struct timeval tv = { .tv_sec = 0, .tv_usec = 500000 }; /* 500ms */ setsockopt(s, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));

超时后read返回-1，errno是EAGAIN或EWOULDBLOCK，这时候你返回主循环做点别的事，比如检查退出标志、写日志、看门狗喂狗。

方案二：epoll。适合一个进程管多个接口，或者和串口、TCP混在一起的事件循环。

int epfd = epoll_create1(0); struct epoll_event ev, events[4]; ev.events = EPOLLIN; ev.data.fd = s; epoll_ctl(epfd, EPOLL_CTL_ADD, s, &ev); int n = epoll_wait(epfd, events, 4, 1000 /* ms */); for (int i = 0; i < n; i++) { if (events[i].data.fd == s) { struct can_frame f; int len = read(s, &f, sizeof(f)); /* 处理 */ } }

SocketCAN的fd是可读事件驱动的，epoll工作得很好，实际项目里我基本都用这套。

4.3 错误帧和bus-off：CAN总线上的"车祸现场"

CAN控制器检测到总线异常时会往接收队列里塞错误帧，can_id带CAN_ERR_FLAG。要看这些帧，得显式打开错误过滤，默认是不投递的：

can_err_mask_t err_mask = CAN_ERR_MASK; /* 全都要 */ setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask, sizeof(err_mask)); /* 或者只关心bus-off */ err_mask = CAN_ERR_BUSOFF;

错误帧定义了十几个错误类别，最有诊断价值的几个我列在下面：

错误帧的data字段里还编码了更多细节，比如CAN_ERR_CRTL会把控制器当前的收发错误计数器落在data[1]里（高4位是RX错误级别，低4位是TX错误级别）。做现场诊断时把这些值打日志，比你自己去猜有用得多。

bus-off是重点：CAN控制器在发送错误计数器超过255后会离线，主动断开总线，这时候你的程序如果只看发送返回值是发现不了的（发送还是会"成功"入队），等真正发现通信断了已经过去好几分钟。所以：

• 要么在ip link时加restart-ms 100让内核自动恢复；
• 要么在程序里监听bus-off错误帧，主动做重连或者告警。

# 命令行也可以随时看计数器和状态 ip -details -statistics link show can0

输出里的berr-counter tx和rx就是当前的错误计数，这是我排查现场问题时第一个执行的命令。

4.4 多帧协议和周期发送：上层还有更省力的选择

CAN单帧只有8字节，实际业务数据往往更长。做分段重组是必要的，但不要自己从头写——内核里有现成的ISO-TP实现（can-isotp模块，PF_CAN下用CAN_ISOTP），它帮你处理多帧的分段、流控、重组，你直接读写大块数据。J1939和CANopen也有对应的内核模块或者成熟开源库。

周期发送也是一个高频需求（比如每100ms发一次心跳）。手写定时器当然可以，但内核有个CAN_BCM（广播管理器）就是干这个的，通过connect()到CAN_BCM协议族，配置好周期和帧内容，内核帮你按点发，抖动比用户态定时器小很多，而且不占你的线程。

不过我想提醒一句：BCM的接口比较绕，学习曲线比RAW陡，如果只是发几路周期报文，用一个timerfd配epoll其实也够用，代码还更好维护。选型看你的报文路数和对抖动的敏感度。

5. 从vcan到实车：SocketCAN联调时最容易翻车的几个地方

5.1 波特率和采样点不匹配：vcan上永远不会暴露的问题

vcan没有物理层，波特率随便设都"通"。所以很多人代码在vcan上跑得好好的，一接真实总线就瞎了。接硬件的第一个动作，是把两端的ip -details link show输出对一遍，确认bitrate完全一致。500k和250k混用是最经典的翻车现场，现象是双方都能自发自收（本地回环），但发给对方一帧都收不到。

采样点不一致更隐蔽。假设你的控制器时钟是40MHz，另一位工程师按80MHz算分频，算出来的位时序看起来都是500kbps，但采样点差了十几个百分点。短距离（小于10米）通信大概率正常，线一拉长到几十米就开始随机报错。解决办法是在ip link时把采样点显式写死：

sudo ip link set can0 type can bitrate 500000 sample-point 0.875

0.875是工业界很常见的约定值，如果你的对端设备手册没写清楚，先按这个来试。

5.2 回环模式、只听模式和终端电阻

这三个东西经常被混在一起讨论，其实用途完全不同。

loopback模式用于控制器自测，收发都在芯片内部闭环，不上总线：ip link set can0 type can bitrate 500000 loopback on。它和vcan的区别是，loopback会真的过一遍控制器的位时序逻辑，所以能验证硬件时钟配置对不对。

listen-only模式让控制器只收不发，连ACK都不发，完全静默：ip link set can0 type can bitrate 500000 listen-only on。接入一个已有的、正常工作的总线做旁路监听时，这个模式是刚需——你要是普通模式插进去，控制器可能会干扰现有通信（特别是在波特率不匹配的时候）。做协议逆向分析，第一件事就是切listen-only。

终端电阻是硬件层的，和软件无关，但现场问题十有八九出在这。CAN总线两端各需要一个120Ω电阻，总阻值60Ω。总线距离短、节点少的时候，缺一两个电阻有时候也能凑合通，但一上量就随机报错。测法很简单：断电后用万用表量CAN_H和CAN_L之间的电阻，接近60Ω说明两端都有，接近120Ω说明只有一端。

5.3 权限、接口命名和重启后的状态丢失

ip link和创建vcan都需要CAP_NET_RAW权限，普通用户跑不了。给程序授权的几种做法：直接sudo（不推荐）、setcap cap_net_raw+ep ./your_program、或者配polkit规则。生产环境我倾向用systemd服务，在unit里加AmbientCapabilities=CAP_NET_RAW，干净且可控。

接口命名这方面，USB适配器插拔后可能变成can1、can2，程序里写死"can0"就会扑空。用udev规则按序列号绑定固定名字：

# /etc/udev/rules.d/80-can.rules SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="ABCD1234", NAME="can_arm"

重启后接口状态（bitrate、up）会丢失，这是内核设计如此。要让配置持久化，用systemd-networkd的.netdev+.network文件，或者NetworkManager的connection配置，或者最土的办法写进rc.local。我一般给客户交付时用networkd，因为配置就是纯文本，现场改波特率不用重新编译。

5.4 时间戳、缓冲区和你该不该开CAN FD

做时序分析的时候，用户态读到的struct timeval精度不够。打开内核时间戳：

int on = 1; setsockopt(s, SOL_SOCKET, SO_TIMESTAMPNS, &on, sizeof(on)); /* 之后用 recvmsg 拿 SCM_TIMESTAMPNS 辅助数据 */

这个时间戳是内核在收包那一刻打的，比你在read返回后再调clock_gettime要准几百微秒到几毫秒，做报文间隔分析（比如判断某个ECU的周期抖动）的时候差别是决定性的。

接收缓冲区溢出是长时间运行程序的隐形杀手。默认的SO_RCVBUF在高负载总线上撑不了多久，报CAN_ERR_CRTL_RX_OVERFLOW的时候数据已经丢了。调大：

int rcvbuf = 1024 * 1024; setsockopt(s, SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));

但要注意内核有上限（net.core.rmem_max），你得先sysctl -w net.core.rmem_max=4194304，否则设了也被截断。而且加大缓冲只是治标，根本解法还是内核过滤器筛掉不关心的ID，加上用户态处理逻辑别做重活。

至于CAN FD，如果你的控制器和上位机都支持，用起来是值得的——数据段从8字节涨到64字节，仲裁段还能保持500k以便兼容老设备，数据段提到2M甚至5M。开启方式：

int enable_fd = 1; setsockopt(s, SOL_CAN_RAW, CAN_RAW_FD_FRAMES, &enable_fd, sizeof(enable_fd));

之后收发用struct canfd_frame。但要注意：混用FD和非FD帧在同一总线上是允许的，前提是控制器支持且配置了fd on，对端老设备会忽略FD帧。是否需要上FD，取决于你的数据量——如果单帧8字节够用，别为了炫技引入这个复杂度。

6. 把示例代码做成能交付的模块：我的封装习惯

前面那段最小程序能验证链路，但直接拿去项目里用会很难维护。我的做法是把SocketCAN封装成一个薄薄的一层，只做三件事：接口的打开/关闭、带超时的收发、错误帧的分类回调。不上第三方库，因为SocketCAN本身够简单，多一层抽象反而增加排查成本。

具体可以拆成两个函数：

/* 返回 fd，失败返回 -1 */ int can_open(const char *ifname, const struct can_filter *filters, int nfilters); /* 读一帧，超时毫秒数；返回1成功，0超时，-1错误 */ int can_recv(int fd, struct can_frame *frame, int timeout_ms); /* 写一帧；返回0成功，-1失败 */ int can_send(int fd, const struct can_frame *frame);

can_open内部把socket、ifindex、bind、过滤器、SO_RCVTIMEO、SO_RCVBUF、错误过滤一次性配好，返回的fd可以用epoll管理。这套接口在我们几个项目里跨了x86和ARM两种平台、三种CAN控制器，一行调用都没改过。

另外一个经验点：把接口名、过滤器表、波特率全放到配置文件里，别硬编码。现场调试时客户随口说一句"换个ID"，你改配置重启就行，不用回公司改代码重新走一遍发布流程。配置文件用最简单的key=value或者JSON都行，反而是格式越简单，现场工程师越好用。

最后提一个我觉得值得所有做CAN开发的人养成习惯的做法：每个CAN相关的项目，都在代码库里放一个sim.sh脚本，内容是前面那段vcan创建命令加上cangen造流量。这样新同事clone下来跑一遍，不用碰硬件就能把整个程序跑通，CI里也能跑。我吃过没有这套东西的亏——有个项目所有测试都依赖实验室里那台带CAN卡的机器，那台机器一挂，整个团队停工两天。后来把vcan虚拟总线接进CI，这类风险就彻底没了。