驱动这活儿，在 OpenHarmony 上做和在纯 Linux 上做，手感差别挺大。同样是点灯、读传感器、跑通一条 I2C 时序，有人三小时搞定，有人卡在编译期一个星期——差别往往不在于写不写得出来，而在于一开始选错了路。OpenHarmony 驱动开发的三条路径：内核态驱动、HDF 驱动框架、用户态驱动，各自有明确的适用边界，选错了要么白白增加调试成本，要么在后续版本升级时被架构债反噬。

这篇内容面向准备在 OpenHarmony 上做硬件适配的开发者，不管你是刚拿到开发板、只会写点 C 的新手，还是从其他嵌入式平台迁过来的老手，都能从里面找到可以直接抄的骨架代码、构建配置和排查思路。我会把三条路径的取舍逻辑、寄存器操作细节、HCS 配置写法、编译集成方式、调试手段一条条摊开讲，重点是那些文档里通常不写、但实际会卡住你的地方。

1. 三条路径的整体设计与选型思路拆解

1.1 先搞清楚"驱动"在 OpenHarmony 里到底指什么

很多人一上手就问"OpenHarmony 驱动怎么写"，这个问题其实不成立，因为 OpenHarmony 并不是一个内核，而是一套设备软件平台，它按资源能力分成轻量、小型、标准三档系统，底下跑的内核也不一样。轻量系统通常跑在资源极紧的 MCU 上，小型系统用的是面向 IoT 的实时内核，标准系统则直接跑在 Linux 内核之上。内核不同，驱动的存在形式就完全不同，这是三条路径存在的根本原因，而不是谁为了标新立异造出来的概念。

在最底层，驱动就是一段能操作硬件寄存器的代码，它需要运行在一个有特权的地方；往上一层，平台为了让驱动可复用、可配置、可跨内核，包了一层统一驱动框架，也就是 HDF；再往上一层，对于那些对时序不敏感、对实时性没要求的设备，干脆把驱动搬到用户态进程里去跑，通过标准设备节点或者服务接口跟应用通信。这三层不是互相替代的关系，而是同一件事在不同抽象层级上的三种表达。

理解这一点很关键：你在选路径的时候，本质上是在回答"我这个设备的驱动，需要跑在多高的特权级别上"。特权级别越高，能做的事越多，但出错代价越大；特权级别越低，越安全、越好调试，但能碰的东西越少。所有选型讨论，最后都收敛到这一个问题上。

1.2 三条路径的边界与决策依据

我把三条路径的关键差异整理成一张表，实际做技术方案评审时可以直接拿去用：

这张表里最容易被忽略的是"故障影响面"和"升级维护成本"这两行。新手往往只盯着性能看，觉得越快越好，于是什么都往内核里塞。实际做过两轮产品迭代的人都知道，一个写错指针的内核驱动能让整机反复重启，定位成本是按天算的；而同样一个 bug 放在用户态进程里，进程挂了重启一下，主业务照跑不误。

我自己的决策顺序是这样的：先问这个设备有没有硬实时要求，中断响应时间能不能放宽到毫秒级；如果能，就往用户态走。再问这个驱动要不要在多个产品形态之间复用、要不要靠改配置而不是改代码来适配不同硬件；如果要，就走 HDF。只有当这两个问题的答案都是"不行"，也就是既需要微秒级响应、又只服务单一产品时，才考虑写裸的内核态驱动。

注意：这个顺序不要反过来。先想到内核态、再想办法往回退，往往会写出一个"半框架化"的四不像，既没有框架的复用性，也没有裸驱动的极致性能。

还有一条隐性约束值得说：团队能力结构。HDF 的学习曲线集中在前两周，把设备服务模型、配置加载时序、生命周期回调这几件事想通之后，后面写起来很快；内核态驱动的学习曲线则是长尾的，你可能写了半年还在踩内存管理和并发保护的坑。如果团队里没有长期做内核的人，硬上内核态驱动是给自己挖坑。

2. 内核态驱动：最直接也最危险的那条路

2.1 内核态驱动的基本结构与加载时序

在标准系统上，内核态驱动就是标准的字符设备驱动，走的是文件操作集合那一套。骨架大致长这样，我把关键注释写在代码里：

#include <linux/module.h> #include <linux/fs.h> #include <linux/uaccess.h> #include <linux/io.h> #define DEV_NAME "demo_chrdev" #define DEMO_IOCTL_GET_VER _IOR('D', 1, int) static int demo_open(struct inode *inode, struct file *filp) { /* 这里做上电、时钟使能等一次性动作，注意不能睡眠的场景别放这 */ return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t len, loff_t *off) { int val = 0x5A; if (len < sizeof(val)) return -EINVAL; /* 用户态指针必须走 copy_to_user，直接解引用必崩 */ if (copy_to_user(buf, &val, sizeof(val))) return -EFAULT; return sizeof(val); } static long demo_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { switch (cmd) { case DEMO_IOCTL_GET_VER: return 0x0100; default: return -ENOTTY; } } static const struct file_operations demo_fops = { .owner = THIS_MODULE, .open = demo_open, .read = demo_read, .unlocked_ioctl = demo_ioctl, }; static int __init demo_init(void) { int ret = register_chrdev(0, DEV_NAME, &demo_fops); if (ret < 0) return ret; return 0; } static void __exit demo_exit(void) { unregister_chrdev(0, DEV_NAME); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL");

这段代码里有两个点必须说清楚。第一，register_chrdev传 0 是让内核动态分配主设备号，这对产品化更友好，避免和已有设备冲突；如果你需要固定主设备号方便用户态直接打开，那就得配合mknod在启动脚本里建设备节点，这一步很多人在调试时忘了做，然后奇怪为什么/dev下找不到设备。第二，copy_to_user和copy_from_user不是可选的好习惯，而是硬性要求，用户态指针在大多数配置下不可直接访问，直接解引用会触发缺页异常，运气好是 oops，运气不好就是整机挂死。

加载时序上，模块初始化函数在insmod或开机自动加载时执行，这时候内核的许多子系统已经就绪，但用户态还没起来。这意味着你可以在init里做寄存器映射、申请中断、注册设备，但不能指望在这时候读取某些依赖用户态配置的参数。我见过有人把设备树解析放在init里没问题，但把校准数据读取放在init里就出问题，因为校准文件在文件系统挂载之后才存在。

2.2 寄存器操作与并发安全

内核态驱动最容易出事的不是逻辑，是并发。同一个驱动可能被多个进程同时打开，中断处理函数和进程上下文可能同时访问同一个寄存器，这时候没有保护就是数据竞争。

寄存器访问本身有几条纪律。第一，用ioremap拿到虚拟地址后，读写要走readl、writel这类封装，而不是直接赋值。原因很实在：这些封装内部带了内存屏障，能保证写操作真正到达硬件，不会被编译器优化掉或者被 CPU 乱序执行打乱。尤其在做"写命令寄存器、再读状态寄存器"这种操作时，缺了屏障可能出现命令还没发出去就去读状态的情况，读回来永远是上一次的结果。

第二，volatile只能在编译器层面阻止优化，挡不住 CPU 层面的乱序，所以不要以为加了volatile就万事大吉。硬件寄存器的访问顺序有强依赖时，老老实实用屏障宏。

第三，共享数据的保护要分清上下文。进程上下文之间竞争用互斥锁，中断上下文和进程上下文之间竞争必须用自旋锁并且关中断，因为互斥锁在中断里会睡眠，睡眠是绝对不允许的。这一条写在内核文档里，但实际项目中仍然是最常见的崩溃原因之一。

static DEFINE_SPINLOCK(demo_lock); static unsigned long flags; static irqreturn_t demo_irq(int irq, void *dev) { unsigned int status; spin_lock_irqsave(&demo_lock, flags); status = readl(base + REG_STATUS); writel(status, base + REG_STATUS); /* 写 1 清零 */ spin_unlock_irqrestore(&demo_lock, flags); return IRQ_HANDLED; }

这段里的spin_lock_irqsave而不是spin_lock，是因为中断处理函数可能在持有锁的时候被打断，如果外面用的是不关中断的版本，就会自己等自己，直接死锁。这类问题在单核调试时看不出来，上了多核立刻暴露，所以务必一开始就写对。

2.3 编译集成到 OpenHarmony 构建体系

代码写完了，怎么编进去是另一个坑。标准系统的内核驱动通常作为内核模块编译，需要在驱动的目录下放一份构建脚本，声明模块名和源文件列表，然后在内核配置里把它打开。

# BUILD.gn 片段 kernel_module("demo_chrdev") { sources = [ "demo_chrdev.c" ] kbuild_options = [ "obj-m += demo_chrdev.o", ] }

实际集成时有三个高频问题。一是头文件路径，内核模块不能用用户态的 libc 头文件，混用会出现类型冲突，报错信息往往指向一些莫名其妙的宏重定义，这时候第一反应应该是检查 include 路径。二是符号导出，如果你要调用内核里其他模块的函数，对方必须用EXPORT_SYMBOL导出过，否则链接阶段就报未定义。三是配置项，很多内核能力默认是关的，你调用的接口明明存在却编不过，八成是配置里对应的开关没打开。排查方法很简单，去内核配置里搜一下相关符号是否存在。

提示：内核态驱动调试期建议先做成可动态加载的模块，不要一开始就编进内核镜像。模块加载失败只是 insmod 报错，编进镜像后出错就是开机起不来，得重新烧录，一轮下来十几分钟没了。

3. HDF 驱动框架：平台化开发的主航道

3.1 HDF 到底解决了什么问题

HDF 是 OpenHarmony 的统一驱动框架，它要解决的核心矛盾是：硬件千差万别，但上层接口最好统一。传统做法是每个设备写一套驱动，上层应用为每个设备写一套适配代码，硬件一换就要改一大片。HDF 的思路是把驱动拆成"逻辑不变的部分"和"硬件相关的部分"，后者通过配置文件描述，换硬件只改配置不改代码。

这个思路带来的直接好处有三个。第一是配置与代码分离，同一份驱动代码配不同的参数就能适配不同板子，这对做多产品线的团队价值极大。第二是跨内核能力，框架层做了抽象，同一套驱动模型在小内核和标准内核上都能跑，减少了移植工作量。第三是驱动服务化，驱动对外提供的不是一堆函数调用，而是有明确接口定义的服务，谁用谁按接口来，耦合度低。

代价也要说清楚：框架引入了一层抽象，会有少量运行时开销；配置文件有自己的一套语法和加载规则，这部分学习成本集中在前几天；出问题时要排查的是"配置有没有被正确加载、匹配规则对不对、生命周期回调有没有按预期执行"，比裸驱动多几个环节。但从我做过的情况看，只要产品超过两个硬件形态，这些成本很快就能赚回来。

3.2 一个 HDF 驱动的骨架与生命周期

HDF 驱动的入口是一个固定结构的对象，包含模块名和三个回调。骨架如下：

#include "hdf_device_desc.h" #include "hdf_log.h" #define HDF_LOG_TAG demo_driver static int32_t DemoDriverBind(struct HdfDeviceObject *device) { if (device == NULL) return HDF_ERR_INVALID_OBJECT; HDF_LOGI("demo bind"); return HDF_SUCCESS; } static int32_t DemoDriverInit(struct HdfDeviceObject *device) { if (device == NULL) return HDF_ERR_INVALID_OBJECT; /* 从配置中读取参数，注意判空 */ const struct DeviceResourceNode *node = device->property; if (node == NULL) { HDF_LOGE("no config node"); return HDF_ERR_INVALID_OBJECT; } /* 初始化硬件、注册服务 */ return HDF_SUCCESS; } static void DemoDriverRelease(struct HdfDeviceObject *device) { HDF_LOGI("demo release"); } static struct HdfDriverEntry g_demoDriverEntry = { .moduleVersion = 1, .moduleName = "demo_driver", .Bind = DemoDriverBind, .Init = DemoDriverInit, .Release = DemoDriverRelease, }; HDF_INIT(g_demoDriverEntry);

三个回调的职责边界要卡死。Bind做服务与设备的绑定，不碰硬件；Init才是真正初始化硬件、注册对外接口的地方；Release负责释放资源，注意它可能不会被调用，所以不要在Release里放必须执行的关键逻辑。这个顺序不是形式主义，因为框架在某些场景下会先Bind一批驱动再统一Init，如果你在Bind里就去操作硬件，时序上可能硬件还没上电。

另一个高频错误是配置文件读取时不判空。配置节点找不到返回空指针，你直接解引用，现象就是驱动加载时整个流程卡住或者异常重启，而日志里可能只有一个很笼统的错误码。养成习惯：所有从配置里取的东西，先判节点存在，再取属性，再判断属性类型和长度是否匹配。

3.3 HCS 配置怎么写才不返工

配置文件是把驱动和设备连起来的关键。通常有两层：一份设备信息配置，声明有哪些设备、各自用什么驱动、加载优先级是多少；一份具体设备的参数配置，写寄存器基址、中断号、GPIO 编号这些。

/* device_info 配置片段 */ demo_device :: device { device0 :: deviceNode { policy = 1; /* 对外提供服务 */ priority = 100; /* 数值越小越早加载 */ preload = 0; /* 按需加载 */ permission = 0660; moduleName = "demo_driver"; /* 必须与 DriverEntry 一致 */ serviceName = "demo_service"; /* 上层按这个名字找服务 */ deviceMatchAttr = "demo_attr"; } }

这里有四个参数极易出错。moduleName必须和代码里的moduleName完全一致，一个字符不差，否则框架找不到驱动，表现是加载流程走完了但Init没被调用，日志里一片安静。priority要理解成"启动顺序"，数值小于等于某个阈值的驱动会被预加载，如果你的驱动依赖另一个驱动提供的服务，必须让自己的优先级数值更大，也就是更晚加载。policy决定驱动是否对外发布服务，不需要对外提供的内部驱动设成 0，避免占用服务查找表。deviceMatchAttr决定了具体参数从哪一段配置里取，写错了会拿到空节点。

参数文件那边的类型不匹配问题更隐蔽。配置里写的是一个整数，你按数组去读，可能不报错但读到垃圾值；反过来配置里是数组，你按整数读，可能只拿到第一个元素。配置写完一定要交叉验证一遍类型，别凭感觉。

3.4 HDF 常用能力与避坑

框架提供的能力里，用得最多的是 IO 服务获取、消息分发和缓冲区传递。获取服务时注意返回值判空，服务可能因为你依赖的驱动还没初始化完而拿不到，这时应该返回失败让框架重试，而不是拿个空句柄继续用。

跨进程传数据用框架的缓冲区机制，注意读写位置指针的维护，写完要翻转，读的时候要从头读，这套逻辑和常见的数据缓冲结构类似。我见过有人在同一次调用里既写又读却没翻转指针，结果读出来的是空数据，排查了半天以为是传输链路问题。

中断和 GPIO 这类外设能力，框架有对应的子系统封装，优先用封装接口而不是自己ioremap去裸操作。封装接口做了资源管理和冲突检查，两个驱动抢同一个引脚时会明确报错，裸操作则是互相踩踏，现象是引脚电平莫名其妙地跳。

提示：HDF 驱动的日志 TAG 一定要定义成有辨识度的名字，最好带上模块前缀。多驱动联调时日志混在一起，TAG 起得随便会让你在几百行输出里找不到自己要的那几行。

4. 用户态驱动：绕开内核的务实选择

4.1 什么时候该选用户态

用户态驱动这个词听起来像是妥协，实际上在很多场景下它是更工程化的选择。判断标准很简单：这个设备的中断频率高不高、响应时间要求是不是微秒级、有没有大量 DMA 搬运。三条里有一条不满足，就要认真考虑用户态。

典型适合用户态的设备包括：温度湿度传感器、光照传感器、按键与指示灯、慢速 ADC、屏幕背光控制、部分电源管理芯片。这些设备的共同特点是数据更新慢、操作简单、出错不影响系统稳定。反过来，高速采集卡、以太网控制器、存储控制器这类，用户态方案要么做不到，要么做出来性能难看。

还有一个经常被忽略的理由：算法融合。很多传感器的原始数据需要跑滤波、标定、融合算法，这些算法往往用第三方库，甚至是用高层语言写的。放内核态意味着你要把算法移植成 C 并且不能调用标准库，工作量和风险都大；放用户态则直接链接库调用，迭代改一行代码重编一次进程就行。

4.2 三种常见的用户态实现方式

第一种是基于标准设备节点。内核里有一个通用的字符设备驱动把硬件暴露成/dev下的节点，用户态程序用标准的打开、读取、写入、控制接口操作。这种方式的优点是通用性强，几乎所有平台都有类似机制；缺点是灵活性受限于内核那边提供的接口，你需要什么特殊功能就得改内核驱动，绕回去了。

第二种是寄存器映射。通过内存映射把一段物理地址映射到进程地址空间，然后直接读写。这条路性能最好，接近内核态的寄存器操作速度，但有前提：这部分地址必须是可以安全映射的，不能是内核正在管理的关键区域。实际使用时通常配合一个简单的内核侧模块只做映射和中断转发，业务逻辑全在用户态。

/* 用户态映射示例 */ int fd = open("/dev/mem", O_RDWR | O_SYNC); if (fd < 0) return -1; void *base = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, PHY_ADDR); if (base == MAP_FAILED) { close(fd); return -1; } uint32_t ver = *(volatile uint32_t *)((char *)base + REG_VERSION);

这段代码里O_SYNC不能省，它保证写操作不被缓存延迟；volatile也不能省，防止编译器把重复读优化成一次读。还有一点，映射长度要按页对齐，物理地址也要页对齐，否则映射会失败，而失败原因往往只返回一个笼统的错误码。

第三种是服务化封装。把驱动能力做成一个系统服务，注册到服务管理框架里，上层通过接口调用。这是最"OpenHarmony 味道"的做法，好处是接口清晰、可以跨进程、权限可控，代价是要写接口定义和桩代码，前期工作量稍大。适合驱动能力要被多个应用使用的场景。

4.3 实操：用户态驱动的服务化封装

以一颗通过 I2C 挂载的传感器为例，服务化封装的落地步骤大致是这样：先定义接口，描述清楚有哪几个方法、参数和返回值是什么；再实现服务端，内部完成 I2C 打开、设备地址配置、寄存器读写、数据换算；然后把服务注册到系统，声明服务名和能力；最后应用侧通过服务名获取代理对象调用。

/* 服务注册关键片段，伪代码风格，重点看步骤 */ static int32_t SensorServiceInit(void) { /* 1. 打开 I2C 控制器节点 */ g_i2cFd = open(I2C_DEV_PATH, O_RDWR); if (g_i2cFd < 0) return -1; /* 2. 设置从机地址与速率 */ if (ioctl(g_i2cFd, I2C_SET_SLAVE_ADDR, SENSOR_ADDR) < 0) goto err; /* 3. 上电并等待稳定，这个延时不能省 */ SensorPowerOn(); usleep(5000); /* 4. 读ID做自检，读不到就别往下走了 */ if (SensorReadId() != EXPECTED_ID) goto err; /* 5. 注册服务对象 */ return RegisterService(&g_sensorService); err: close(g_i2cFd); g_i2cFd = -1; return -1; }

这段里有两个经验点。第 3 步的延时很多人嫌慢就删了，然后出现"偶尔读不到 ID"的偶发问题，本质是器件上电到稳定需要时间，删了就是拿稳定性换几毫秒。第 4 步的自检是必须的，它能让你在初始化阶段就发现硬件没焊好、地址配错、总线被占这些问题，而不是等到上层调用时才报一个含义模糊的错误。

5. 三条路径的调试手段与问题排查实录

5.1 日志与调试工具对照表

三条路径的调试手段差别很大，用错工具会浪费大量时间：

内核态排查有个常用手法是看中断计数。如果中断注册成功但计数一直是零，说明硬件根本没产生中断，问题在硬件侧或者中断配置；如果计数在涨但业务没反应，问题在处理函数里的逻辑。这个二分法能快速把问题范围砍一半。

用户态排查的优势是可以单独重启。我习惯在用户态驱动里加一个自恢复逻辑：初始化失败就等一小段时间重试，重试若干次仍失败则上报错误但不退出进程。这样偶发的总线冲突不会导致整个功能消失，日志里也能留下完整的失败轨迹。

5.2 常见问题速查表

这张表里"偶发"两个字出现的频率最高，这类问题最难查，因为它们往往和系统负载、启动顺序、硬件批次相关。我的经验是：凡是偶发问题，先怀疑时序和初始化顺序，再怀疑并发，最后才怀疑硬件坏。硬件批次问题的比例远低于前两者。

5.3 几个实际踩过的坑

第一个坑是构建产物没更新。改了驱动代码，编译也过了，跑起来行为没变，查了两小时发现烧录的还是旧镜像。这类问题现在我会在初始化日志里打一个版本号或者编译时间，一眼就能确认跑的是不是最新代码，成本几乎为零，收益极大。

第二个坑是配置文件的注释。配置语法里注释的写法和常见语言不完全一样，用错了会导致整段配置被当成无效内容跳过，而且不报错。表现就是某个设备的参数全是默认值，行为诡异。解决办法是改完配置后，把关键参数打印出来确认一遍，别相信"我写对了"。

第三个坑是优先级设置反了。驱动 A 依赖驱动 B 提供的服务，结果 A 的优先级数值比 B 小，A 先初始化，拿不到服务就失败了。这类问题在单驱动调试时完全不会出现，一集成到完整系统就暴露。所以从第一天起就要把依赖关系画出来，按依赖顺序排优先级。

注意：驱动之间的隐式依赖是最难维护的架构债。能通过服务查找加失败重试解决的，就不要靠优先级硬排，后者在系统变复杂后必然出问题。

6. 工程化落地：性能、兼容与长期维护

6.1 三条路径的性能量级差异

做过对比测试的人会有直观感受：同样是读一个寄存器，内核态驱动一次操作在纳秒到微秒量级，HDF 因为多了一层框架分发，开销增加但仍在同一量级，用户态通过内存映射访问也能做到接近内核态，但如果每次都走系统调用或者跨进程通信，开销会上到几十微秒甚至更高。

这个差异意味着什么？如果你的设备每秒产生上千次中断，用户态方案的上下文切换开销就不可接受了；如果设备每秒只更新几次数据，那点开销完全可以忽略。所以在做选型时，先算一下设备的实际数据速率，别凭感觉。

另一个常被忽略的性能点是日志。内核态驱动里一行高频打印，可能让系统整体吞吐下降一个可观的比例。调试期开着无所谓，量产版本必须把日志分级，只保留错误级别。这一条吃过亏的人都懂。

6.2 版本升级与兼容性

内核态驱动和内核版本强绑定，内核一升级，内部接口、数据结构、宏定义都可能变，驱动要跟着改。这是长期维护成本的主要来源。如果你做的是要走多个版本的产品，尽量把驱动放在 HDF 框架里，框架层做了屏蔽，升级时的改动量小得多。

HDF 驱动的兼容性关注点是配置格式和框架接口。配置格式在小版本之间通常是稳定的，但新增能力会带来新的配置项；框架接口的演进相对克制，但重大版本仍可能调整。做法是把配置和代码都纳入版本管理，升级时先做一次全量回归，别只测改动的部分。

用户态驱动的兼容性最好，因为它依赖的是标准设备节点或者服务接口，这两者都很稳定。唯一要留意的是权限模型的变化，新版本可能收紧设备节点的访问控制，导致原来能打开的节点打不开了，现象是权限相关的错误码，改配置或者调整进程权限组即可。

6.3 交付清单与代码评审要点

不管走哪条路径，交付前我都会过一遍这份清单：资源申请是否有对应的释放路径，包括错误分支；所有外部输入是否判空、判长度、判类型；中断上下文里有没有可能睡眠的调用；并发访问的共享数据是否有明确保护；日志是否分级，量产配置下是否关掉了调试输出；配置文件的每个字段是否都能对应到代码里的一次读取。

代码评审时我最关注的不是功能实现，而是错误处理。一个驱动写得好不好，看它的错误分支就知道了。初始化到第五步失败，前面四步申请的资源释放了没有；读配置拿到空指针，是返回错误还是继续往下走；用户传进来的长度是零或者超大值，有没有边界检查。这些地方写扎实了，现场问题能少一大半。

提示：给每个驱动配一份最小自测脚本，覆盖正常初始化、重复初始化、异常参数、拔插恢复这几个场景。这份脚本在后续每次改动后跑一遍，比人肉回归可靠得多。

最后说点个人体会。我刚开始做这类开发时，总觉得把驱动写进内核才叫"真正的驱动"，用户态方案像是偷懒。做了几个产品之后想法完全变了：能让系统稳定运行、能让团队快速迭代、能让问题在十分钟内定位的方案，才是好方案，跑在哪个特权级根本不重要。现在我的默认选择是 HDF 框架，遇到明确的性能瓶颈再往下沉，遇到算法密集的部分往上抬，三条路径不是三选一的单选题，同一个产品里混着用才是常态。真正要练的功夫，是把边界划清楚，然后每一层都写扎实。