1. 一条SPI总线挂8个从设备：项目边界与隐藏难点
如果你在 Linux 驱动开发里混过一段时间，多半见过类似标题：8 个 SPI 设备、device_add、板级注册。第一次接到这种需求时，我还觉得挺简单——SPI 是一条总线拖多个从机，设备树里多写几个子节点，驱动里多申请几个私有数据，最多再查查片选，能有多复杂？等真正把 8 路设备全部跑起来，才发现问题远不止"写 8 行节点"这么简单。整条链路上任何一个环节没对齐，都会出现"节点生成了驱动不 probe""probe 成功了数据却是乱的""7 个正常第 8 个怎么都不动"这类现象。
先说清楚这个项目的真实边界。SPI 本身是主从结构，一条完整的总线由 SCLK、MOSI、MISO 和若干路 CS 片选组成。8 个从设备共享时钟线和数据线，靠各自的片选信号决定谁在某个时刻占用总线。Linux 内核的 SPI 子系统里，每个从设备会被抽象成一个struct spi_device，每个片选对应一个"设备地址"。而标题里反复出现的device_add，是 Linux 设备模型里最核心的注册函数，它把设备对象挂进内核的设备树结构，触发总线上的驱动匹配，最终调用驱动里的probe。可以说，SPI 驱动从"设备存在"到"驱动生效"，中间隔着的正式一步就是device_add。
为什么"8"这个数字会成为一个坎？因为超过 5、6 路之后，硬件层面的 CS 路由、中断引脚、电源负载、DMA 通道，以及软件层面的设备树节点管理、并发总线访问、驱动匹配顺序，全都会叠加在同一条总线上。8 路是从板级设计到驱动开发都需要整体考虑的临界规模。这篇文章就把我在这类项目里的完整思路拆开，适合刚接触 Linux SPI 驱动的人，也适合那些已经写了简单 SPI 驱动、但没处理过多设备批量注册的工程师。你能从里面看到 device_add 在整个注册链路中的位置、两种注册方式的选型对比，以及一路设备出问题时如何从现象反推到根因。
2. device_add在SPI设备注册链路中的真实位置
很多新手会有个误解：以为写驱动就是填一个struct spi_driver，配一个 compatible，剩下全靠内核"自动完成"。实际上，驱动能够被调用，前提是设备对象已经正确注册到了 SPI 总线。而设备对象的落地，靠的就是device_add这一核心函数。理解它的调用位置，比背 API 更有价值。
2.1 注册链路总览：两种入口殊途同归
在当前主流内核里，SPI 设备的注册有两条典型路径。第一条是设备树路径：内核启动时，of_platform_populate扫描设备树里的 SPI 控制器节点，控制器驱动初始化完成后，of_spi_register_devices会遍历控制器节点下的每个子节点，逐一调用of_register_spi_device。第二条是板级代码路径：在没有设备树或者设备树不方便覆盖的平台上，可以提前声明struct spi_board_info数组，交给spi_register_board_info，内核在 SPI 控制器注册时通过scan_boardinfo扫描这个表。
两条路径走到最后都会汇聚到同一个出口：spi_new_device。这个函数先调用spi_alloc_device分配一个struct spi_device，设置好controller指针和chip_select，然后调用spi_add_device。spi_add_device内部做一系列 SPI 子系统特有的初始化后，才真正调用device_add。
// 设备树路径 of_spi_register_devices() -> of_register_spi_device() -> spi_new_device(ctlr, &bi) -> spi_alloc_device(ctlr) -> spi_add_device(spi) -> device_add(&spi->dev) // 板级代码路径 spi_register_board_info(bi, n) -> scan_boardinfo(ctlr) -> spi_new_device(ctlr, &bi) -> spi_alloc_device(ctlr) -> spi_add_device(spi) -> device_add(&spi->dev)所以，不管你是通过设备树还是通过spi_board_info注册设备，最终都要经过device_add。这也就是说，如果device_add之前的环境有问题，后面probe怎么调都白搭。那spi_add_device在调用device_add之前到底做了什么？这才是关键。
2.2 spi_add_device在调用device_add之前做了什么
直接调用device_add并不是不行，但你会发现 SPI 设备的很多字段根本没初始化到位。spi_add_device承担了几件很重要的事：
第一，检查片选号是否合法。每个 SPI 控制器能支持的片选数量由num_chipselect决定，如果传入的chip_select超过这个数，spi_add_device会直接返回错误，后面的设备树节点就静默消失了。第二，初始化spi_device与控制器、总线之间的关系：spi->dev.parent指向控制器的设备对象，spi->dev.bus指向&spi_bus_type。这两个指针决定了设备挂在哪棵树上，以及匹配驱动时走哪个总线的匹配逻辑。第三，根据控制器的能力做兼容性修正，比如mode位、max_speed_hz，有的控制器硬件只支持特定模式，需要在这里做必要调整。
// spi_add_device 关键路径（伪代码级理解） int spi_add_device(struct spi_device *spi) { struct spi_controller *ctlr = spi->controller; // 1. 片选合法性检查 if (ctlr->num_chipselect && spi->chip_select >= ctlr->num_chipselect) { dev_err(&ctlr->dev, "chip select %d out of range\n", spi->chip_select); return -EINVAL; } // 2. 绑定父子关系和总线类型 spi->dev.parent = &ctlr->dev; spi->dev.bus = &spi_bus_type; spi->dev.type = &spi_device_type; // 3. 设置DMA掩码和默认参数 spi->dev.coherent_dma_mask = ctlr->dma_mask; spi->dev.dma_mask = &spi->dev.coherent_dma_mask; // 4. 真正进入设备模型 return device_add(&spi->dev); }这里有一个容易忽略的点：spi_add_device内部设置的dma_mask和dma_coherent_mask。如果你绕过它直接device_add，后续驱动里申请 DMA buffer 时会出很多莫名其妙的地址映射问题。我见过一个例子，驱动里用dma_alloc_coherent申请内存，返回的地址 CPU 能访问，但 SPI 控制器 DMA 读出来全是错的，查了很久才发现是设备对象根本没有正确的 DMA 掩码，地址范围超出了控制器可访问的窗口。
2.3 device_add的三步本质：sysfs、总线链与probe触发
跳过spi_add_device直接调用device_add，看起来像绕过了中间层，实际是丢弃了 SPI 子系统为设备对象做的上下文准备。而device_add本身做了三件你可以直观感知的事。
第一，把设备对象注册进 sysfs，生成/sys/bus/spi/devices/spiX.Y这样的目录。X 是控制器编号，Y 是设备在控制器下的片选号。这个目录是你在板上最直观的"设备存在"证据。第二，把设备挂到 SPI 总线的设备链表上，内核在驱动注册或设备注册时都会尝试做一次匹配。第三，如果当前已经有匹配的驱动，直接调用驱动的probe；如果暂时没有，则等待驱动注册后重新匹配。这也是"设备节点在、驱动也编进去了、但 probe 就是没跑"一类问题的根源，两者注册的先后顺序在多数情况下不会造成影响，但若驱动中依赖了其他设备初始化，匹配时机就会变得关键。
我在这类项目里经历过的最典型问题，就是平台驱动里直接声明的compatible与设备树节点不一致。设备节点生成了，spiX.Y目录也在，但驱动就是不 probe。原因往往不是device_add的问题，而是节点里的compatible字符串与驱动of_device_id表没有匹配上。记住一点：device_add只是把"设备存在"这件事告诉内核，它不负责保证"驱动一定生效"。设备能不能被驱动接管，还要看总线匹配这层关卡。
3. 8路设备批量注册：设备树与板级代码表的取舍
既然一条 SPI 总线上要挂 8 个从设备，选择注册方式就是第一个分岔口。我用过两种方案，也都踩过对应的坑，这里把各自的特性讲透，你可以直接照着自己项目的情况做取舍。
3.1 设备树方案：把8路参数写在明面上
设备树方案的最大优势是表达力强。每个从设备一个子节点，CS 编号对应reg，时钟频率、SPI 模式、中断号全部独立描述。8 路设备即使参数各不相同，在节点里也一目了然。这是我最终选择的方案，因为它让"硬件连接关系"和"软件设备参数"唯一对应，排查问题时可以直接对着原理图核对。
&spi1 { status = "okay"; num-cs = <8>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_spi1>; dev0: device@0 { compatible = "example,spi8-dev"; reg = <0>; spi-max-frequency = <1000000>; spi-cpol; spi-cpha; interrupt-parent = <&gpio0>; interrupts = <10 IRQ_TYPE_EDGE_RISING>; }; dev1: device@1 { compatible = "example,spi8-dev"; reg = <1>; spi-max-frequency = <2000000>; }; // dev2 ~ dev6 省略 dev7: device@7 { compatible = "example,spi8-dev"; reg = <7>; spi-max-frequency = <500000>; }; };注意num-cs = <8>这个属性，它告诉 SPI 控制器驱动"你最多支持 8 个片选"。如果没写或者写小了，后面的设备节点即使reg写 7，也会在spi_add_device阶段因为片选越界被直接丢弃。这种错误不容易察觉，因为设备树编译不报错，内核启动日志也未必显示明显告警，就是少了几个设备节点。
3.2 spi_board_info方案：没有设备树时的替代
老一点的内核或者不带设备树的平台，用spi_board_info表更合适。它的核心思路是在 C 代码里声明一个数组，每个元素描述一个 SPI 设备的总线号、片选号、模式、最高频率和中断。注册时机是在 initcall 阶段，调用spi_register_board_info把表挂到全局链表里，等对应 SPI 控制器注册时逐个匹配生成设备。
static struct spi_board_info spi8_board_info[] = { { .modalias = "example-spi8", .bus_num = 1, .chip_select = 0, .mode = SPI_MODE_0, .max_speed_hz = 1000000, }, { .modalias = "example-spi8", .bus_num = 1, .chip_select = 1, .mode = SPI_MODE_0, .max_speed_hz = 2000000, }, // ... { .modalias = "example-spi8", .bus_num = 1, .chip_select = 7, .mode = SPI_MODE_0, .max_speed_hz = 500000, }, }; spi_register_board_info(spi8_board_info, ARRAY_SIZE(spi8_board_info));这种方式的好处是灵活，设备参数可以用宏定义或条件编译控制，适合设备树不方便改的调试环境。缺点也同样明显：硬件连接关系埋在代码里，换一个板子就要改一大堆数组，扩展性和可读性都差。还有一点容易忽略——表里的bus_num和chip_select组合必须唯一。如果同一个总线号+片选号被注册两次，后续那次不会生效，而且不会有明显的日志提示。
3.3 选型对照与我的选择
我自己在项目里的选择是设备树方案，原因是 8 路设备的参数差异实在太大：有的设备要求最高 2MHz，有的只能跑 500kHz；有的用 SPI Mode 0，有的必须 Mode 3；还有几个设备需要中断引脚。这些硬件差异如果全部用spi_board_info来表达，数组会变得很臃肿，而且每次调整硬件后都要重编内核镜像。设备树方案里，每次改参数只需要修改 dts 源文件，重新编译 dtb，内核本身不用动。
但如果你只是快速验证 Linux SPI 驱动流程，或者跑在一个不支持设备树的早期内核上，spi_board_info会更直接。它不依赖 DTC 工具链，也不会因为节点缩进写错导致整个设备树解析失败。
下面这个对照表可以帮你快速判断：
| 对比维度 | 设备树方案 | spi_board_info 方案 |
|---|---|---|
| 参数可读性 | 高，硬件对应关系直观 | 低，需要对照代码数组 |
| 修改成本 | 改 dts + 编译 dtb | 改 C 代码 + 重编内核 |
| 片选越界检查 | 依赖内核运行时检查 | 同样依赖，但数组可枚举 |
| 多设备差异表达 | 每个节点独立描述 | 靠数组元素区分 |
| 调试排错便利性 | 可用 dtc 反编译确认 | 可用 printk 逐步打印 |
| 适合场景 | 现代内核 + 复杂多设备 | 无设备树或快速验证 |
选型只是第一步，真正磨人的是注册完之后的问题排查。
4. probe没有触发的完整排查链路：从节点消失到数据错乱
8 路设备在开发调试阶段很少能一次性全通。我遇到的第一个问题就是：内核起来后，/sys/bus/spi/devices下只有 7 个设备目录。这个现象极其典型，也极具迷惑性，因为系统没有崩溃，其他 7 路都工作正常，看起来像"漏写了一个节点"。实际上问题几乎都出在设备树或者注册链路前段。
4.1 现象一：设备节点只出现7个
确认方法很简单：启动后执行ls /sys/bus/spi/devices/，数一数spi1.X的目录个数。如果少了一个，先把目光投向 dmesg，搜索spi开头的信息，很多情况下会看到类似 "chip select 7 out of range" 的提示。找不到也没关系，直接反编译 dtb：
dtc -I fs /proc/device-tree -O dts > dump.dts grep -A 20 "spi1" dump.dts重点检查三处：num-cs是否小于实际设备数量、缺失设备的reg是否越界、子节点是否被status = "disabled"显式关闭。我那次就是因为从第 5 路起把reg写成了 4、5、6、7，但硬件上第 5 路接在 CS5，第 8 路接在 CS7，结果reg=7的节点和之前某一路冲突，导致第 8 路始终建不起来。这提醒我一件事：设备树的reg必须严格等于硬件片选编号，不能只按"第几个设备"来写，否则节点虽然能编译通过，实际挂载时片选号会被内核忽略或错配。
4.2 现象二：节点生成了但probe不执行
所有设备目录都在，但dmesg里只有一半的 probe 记录。这种情况基本可以判定为"设备与驱动没匹配上"。在 SPI 总线上，设备侧和驱动侧各有一组匹配依据。设备侧是节点里的compatible字符串，驱动侧是of_device_id表中的字符串。
static const struct of_device_id spi8_dt_ids[] = { { .compatible = "example,spi8-dev", }, {} }; MODULE_DEVICE_TABLE(of, spi8_dt_ids); static struct spi_driver spi8_driver = { .probe = spi8_probe, .remove = spi8_remove, .driver = { .name = "spi8-dev", .of_match_table = spi8_dt_ids, }, }; module_spi_driver(spi8_driver);常见错误是驱动里的 compatible 写成了"example-spi8"（短横线）而设备树里是"example,spi8-dev"（逗号）。字符串比对严格区分大小写和符号，错一个字符就不会匹配。排查时可以直接读 sysfs 里的 modalias，看内核实际为设备生成的匹配名是什么：
cat /sys/bus/spi/devices/spi1.0/modalias对比驱动of_device_id表的字符串，通常一眼就能找出不一致的地方。
4.3 现象三：probe执行了但数据全乱
比不 probe 更头疼的是 probe 执行了，8 路设备也都能读，但读回来的数据要么全 FF，要么大量错位。这种问题的排查思路不再是设备树和匹配，而要回到硬件与时序。
我遇到过最典型的一幕：某一路设备每次读到的都是上一路设备写入的数据，翻来覆去查驱动代码都看不出问题，最后拿着万用表量了片选通路才发现，那条 CS 信号压根没连到目标设备的 CS 引脚，而是在板上被相邻设备旁路掉了。也就是说，reg=5的设备，硬件却落在 CS7 上。节点存在、probe 成功、读写指令也都发到了 SPI 控制器，但控制器驱动选择的片选是 5，硬件设备却在等 CS7，两条线就这么错开了。
这类问题靠调试软件很难定位，最有效的手段是做一个简单的回环测试：把同一块板子上某一路设备的 MOSI 和 MISO 短接，然后用一个小工具往该路发送已知数据，看返回是否一致。如果不一致，而其他路正常，基本可以确定是片选映射或者 SPI 模式的问题。SPI Mode 设置错误时，现象也有辨识度：不是完全没有数据，而是返回的字节像是被左移或右移了一位，夹杂噪声。
4.4 把排查链路固化成一页检查清单
踩过这些坑之后，我总结了一个固定排查顺序，每次新增一路设备都按这个顺序过一遍，效率很高：
- 先核对硬件：CS 信号是否确切连到目标设备的片选引脚，中断引脚是否复用冲突。
- 再核对设备树：
reg是否等于硬件片选号，num-cs是否足够，节点是否 disabled。 - 查启动日志：dmesg 中搜索 spi、spi1、chip select 关键字。
- 查 sysfs 目录：
/sys/bus/spi/devices/下设备目录数量，modalias内容。 - 查驱动匹配：
of_device_id表中的 compatible 与设备树完全一致。 - 查 probe 日志：驱动里每个关键步骤至少留一行
dev_dbg，避免 probe 返回值被内核静默吞掉。
这个顺序从硬件到软件，从注册到匹配，覆盖了大多数"设备不生效"的场景。真正需要device_add级别深挖的情况反而很少，但你要理解它的存在——所有前面的检查，最终都是为了让device_add之后那次合理的匹配和 probe 能发生。
5. 8路并发场景下的内存、中断与私有数据设计
8 路设备全部注册成功，只是开始。这些设备在同一时刻都要访问总线时，真正的并发压力才会暴露出来。SPI 是时分复用总线，同一时刻只能有一个设备占用 SCLK/MOSI/MISO，内核 SPI 子系统会为每个控制器维护一把总线锁，保证spi_sync和spi_async不会跨设备交错。但锁只能保证"总线不会被两个事务同时占用"，不能替你想清楚"每个设备的数据缓冲怎么管理、中断怎么分配、私有状态放哪里"。
5.1 带宽占用率：8路共享一根时钟线
在设计 8 路设备的访问策略前，先算一笔带宽账。假设设备 0 每秒钟要发起 100 次事务，每次事务传输 8 字节，总线时钟为 1MHz：
单次事务耗时 = 8 字节 × 8 位 / 1MHz = 64µs 设备 0 每秒占用 = 100 × 64µs = 6.4ms 单路占用率 = 6.4ms / 1000ms = 0.64%
看起来很低是吧？但如果 8 路都是这个频率，总数也就 5% 左右，没什么压力。真正需要警惕的是高频率大块数据传输的场景。比如某一路设备以 2MHz 时钟每次传 256 字节，每秒 500 次：
单次事务耗时 = 256 × 8 / 2MHz = 1024µs ≈ 1ms 单路占用率 = 500 × 1ms = 500ms / 1000ms = 50%
也就是说，这一路设备已经吃掉了一半的总线时间，其他 7 路的任何访问都会被挤到后面排队。8 路设备叠加时，如果总占用率超过 60%，突发访问的延迟会明显上升，甚至触发上层的"读超时"重试逻辑。所以我在设计时会给每一路统计事务耗时，确保总占用率留出足够裕量，而不是等到系统跑起来才发现某路设备频繁报错。
5.2 共享DMA缓冲与总线锁
8 个设备各自维护独立 DMA buffer，内存消耗是 8 倍。如果你的每次事务都要 4KB buf，8 路就是 32KB，看起来不多，但若还要考虑 align、cache line 对齐、多个事务并行下发，实际占用会成倍增长。稳妥的做法是维护一个共享的 DMA 缓冲池，配合互斥锁使用：每次发起传输前从池里取一块 buffer，传输完成后释放。
struct spi8_pool { void *tx_buf; void *rx_buf; dma_addr_t tx_dma; dma_addr_t rx_dma; struct mutex lock; };要注意，SPI 控制器本身有总线锁，但这把锁只保证事务级别的串行化，不保证驱动自己的状态一致。比如你在spi_sync前后要访问某个共享计数器，或者要更新某个设备的私有寄存器缓存，这些都需要自己加锁。总线锁和业务锁是两回事，别混为一谈。
5.3 私有数据结构体：让每个spi_device各管各的
8 路设备挂在同一个 SPI 控制器下，ypically 使用同一个spi_driver，但每个spi_device的硬件参数、寄存器状态、回调函数都可能不同。最忌讳的做法是在驱动文件里声明一个全局数组，按下标存每个设备的状态。这个做法在 1~2 路设备时还能凑合，8 路时一点小改动就会把状态搞串。
正确做法是把每个设备的状态封装进私有结构体，在probe时分配，用spi_set_drvdata挂到设备上，需要时通过spi_get_drvdata取回：
struct spi8_priv { struct spi_device *spi; struct mutex lock; u8 current_mode; u32 max_speed; void *tx_buf; void *rx_buf; struct completion transfer_done; }; static int spi8_probe(struct spi_device *spi) { struct spi8_priv *priv; priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; priv->spi = spi; priv->current_mode = spi->mode; priv->max_speed = spi->max_speed_hz; mutex_init(&priv->lock); init_completion(&priv->transfer_done); spi_set_drvdata(spi, priv); return 0; }这样每个spi_device的 driver_data 都指向自己的私有状态，互不干扰。即使 8 路设备的参数各不相同，代码里也只需要一套 probe 逻辑，靠私有数据区分具体设备。
5.4 中断：8路设备共用一个中断号的隐患
很多 SPI 从设备会在完成一次转换后拉高中断脚。8 路设备如果全部接到同一个 GPIO 中断入口，驱动里就要准备好"一次中断可能对应多个待处理的设备"。不要在中断处理函数里同步发起 SPI 读操作，而应该只标记事件位，唤醒对应的工作队列，在 process context 里按顺序读取各设备。否则中断上下文里的 SPI 传输会和正常的spi_sync争用总线锁，轻则增加延迟，重则导致死锁。
我在这类项目里的做法是：中断处理函数里只调用disable_irq_nosync加上schedule_work，真正读取数据的逻辑放到 workqueue 里完成。这样既保证了中断响应速度，也让 SPI 操作都在安全的上下文里执行。8 路设备同时来中断时，workqueue 会串行处理，配合前面的带宽估算，不会把总线压垮。
6. 启动验收与持续压测：用sysfs和回环测试把8路设备钉牢
设备驱动写完，系统能起来，并不代表 8 路设备真的可靠。我习惯把验收分成两个阶段：启动后的静态巡检，和运行中的持续压测。第一阶段花 3 分钟，能过滤掉七成问题；第二阶段跑一晚上，能暴露并发和时序问题。
6.1 启动后的三分钟巡检
每次重启后，第一件事是看设备目录：
ls /sys/bus/spi/devices/正常情况应该能看到 8 个spi1.X目录。接着看驱动是否接管了每个设备：
cat /sys/bus/spi/devices/spi1.5/uevent如果DRIVER=spi8-dev出现，说明该设备的驱动绑定成功。再用 dmesg 过滤 probe 日志，确认 8 路全部打印了初始化信息。这些检查做完，基本可以确定设备树、注册链路、驱动匹配都没问题。这时候还没必要碰数据，先把"设备存在且被驱动接管"这一步钉死。
6.2 回环测试与模式校验
回环测试是验证 SPI 时序和模式最直接的手段。找一路设备，把 MOSI 和 MISO 短接，写一个小工具依次发送 0x55、0xAA、0x00、0xFF 这类特征模式，读回后比对。如果读回值和发送值一致，说明当前设备的 CPOL/CPHA 设置基本正确；如果不一致，重点核对spi-cpol、spi-cpha属性与芯片手册的要求。
我建议 8 路设备全部做完回环，而不是只测一路。因为不同设备可能跑在不同模式，一路正常不代表其他路也正常。实测中，Mode 0 的设备如果配成 Mode 1，读回数据会呈现明显的 1-bit shift；Mode 2 的设备配成 Mode 3，数据线上会出现多余的翻转沿。这类问题在回环测试中暴露得最快。
6.3 长时间并发压测的监控指标
回环测试通过后，进入长时间验证阶段。我会写一个简单的压力脚本，让 8 路设备同时周期性地发起读写，持续 8 小时以上，期间监控几个核心指标：
| 监控指标 | 正常情况 | 异常信号 |
|---|---|---|
| dmesg 中 spi timeout 次数 | 0 | 出现 "spi transfer timeout" |
| 设备读写返回错误率 | 0% | 随机出现 -EIO、-ETIMEDOUT |
spi_sync平均耗时 | 稳定在预期值附近 | 波动剧烈，偶发 10 倍以上增长 |
| 中断触发次数 | 与设备转换频率匹配 | 频繁丢失中断或重复触发 |
如果压测中发现某一路设备偶尔超时，不要急着怀疑驱动代码。先用逻辑分析仪抓一下 SCLK、CS、MOSI、MISO 四根线，确认设备是不是真的响应了。时序问题往往比代码问题难定位，但也是最值得花时间的，因为它直接决定系统在真实工况下的稳定性。
8 路设备同时工作，真正考验的不是device_add那一下，而是你在设备树、DMA 缓冲、并发锁、中断处理这些环节有没有留够设计余地。设备能注册上只是入场券，把 8 路设备在长期运行中稳定地协调起来，才是项目里最花时间、也最能积累经验的部分。
我自己在这类项目里的体会是：宁可先在 1~2 路设备上把链路完整跑通，包括设备树、驱动匹配、DMA 和中断，再扩展到 8 路，也不要一开始就铺开 8 路齐头并进。前几路踩过的坑，后面几路基本都会以不同形式再出现一次，但至少你已经有了排查的模板。设备注册是最容易验证的环节，也是最容易让人掉以轻心的环节——device_add之后的每一天，才是真正的战场。
