做OpenHarmony硬件开发，我最常被问到的一句话是：“板子拿到手，系统也烧进去了，接下来该干嘛？”我的回答永远是一样的——先别急着写业务代码，把调试三板斧练熟：串口、日志、hdc。这三样东西，就是你跟开发板之间的“眼睛”和“耳朵”。系统起没起来、内核报了什么错、应用为什么崩溃、网络通不通，所有问题的答案，都得靠它们挖出来。
这篇内容原本是我们“万物智能之开源鸿蒙OpenHarmony系统实战开发系列教程”里硬件调试部分的底稿，面向的是刚拿到开发板、准备从零开始啃OpenHarmony的开发者，也欢迎那些已经在ARM板子上跑过Linux、想快速上手OpenHarmony的老手。不管你是做智能家居、物联网网关，还是想折腾一下x86电脑版OpenHarmony，这套调试方法都是通用的。我还会把最近折腾电脑版x86 OpenHarmony时踩过的坑一并整理进来，这块环境比ARM开发板更特殊，调试思路也有差异，值得单独聊聊。
1. 内容整体设计与思路拆解
1.1 为什么是“三板斧”，而不是一套完整方法论
“三板斧”这个说法，源自程咬金的故事，意思是招数不多，但招招管用。硬件调试所谓的完整方法论，其实可以写一本书：JTAG调试、逻辑分析仪、示波器、性能剖析、内存检测、功耗分析……工具链极其庞大。但对绝大多数做OpenHarmony应用开发、系统移植或者设备适配的工程师来说，日常高频使用的就是串口终端、日志系统和hdc调试桥这三板斧。
这三板斧覆盖了调试最主要的三个场景。第一，系统起不来，你要看引导日志和内核日志，这得靠串口。第二，系统起来了但行为不对，你要看应用日志和系统服务日志，这得靠OpenHarmony的hilog日志系统。第三，你想直接操作设备、传文件、查进程、抓trace，这得靠hdc。换句话说，串口是“生命的体征”，日志是“行为的记录”，hdc是“医生的双手”。把这三样用好，90%以上的问题都能快速定位到模块级别，剩下的才是示波器、逻辑分析仪的活儿。
设计这套内容时，我刻意没有把工具安装和命令参数堆在一起，而是按“问题现象 -> 需要什么工具 -> 怎么操作 -> 常见坑”的逻辑展开。这样做的原因很简单：调试是一项以问题为导向的工作，你只有先知道“要解决什么问题”，才会真正理解“为什么要用这个命令”。如果上来就背一串串口参数和hdc命令，用不了三天就全忘了。
1.2 这套调试方案适用的硬件场景
OpenHarmony的硬件形态非常多样。小而全的有Hi3861这样的WiFi IoT模组，主流的是DAYU200（RK3568）、DAYU210这样的开发板，还有人在各种派、国产化板卡上移植，甚至有人直接在x86的迷你主机上装OpenHarmony。不同硬件，调试手段的侧重点略有不同，但三板斧的底层逻辑完全一致。
- 对IoT小设备，串口几乎是你唯一的调试通道，日志系统相对精简，hdc通常不可用。
- 对标准开发板，串口、hilog、hdc三者缺一不可，配合起来效率非常高。
- 对x86电脑版，串口不一定方便引出，hdc网络调试反而成了主力，日志拷出来分析也是常见做法。
所以我这篇内容会尽量覆盖这些差异，特别是在“板斧二”和“板斧三”里，我会特别说明x86环境下的变通方案。你先把ARM开发板上这套逻辑跑通，再去看x86环境，会发现底层原理全是通的。
2. 上手前的关键准备：串口线、烧录镜像与基础环境
2.1 串口连接：三根线里的门道
串口是调试的第一板斧，但很多人第一关就卡住——插上没输出。这里面的坑，远不止“TX接RX”这么简单。
首先，硬件连接。绝大多数开发板（比如DAYU200、DAYU210、各种派类板卡）上都有调试串口引脚，通常是3.3V TTL电平，通过USB转串口模块（CP2102、CH340、FT232等）连接电脑。接法口诀是：板子的TX接模块的RX，板子的RX接模块的TX，地线必须共地。光说不练容易记混，我的习惯是拿万用表量一下电平，或者直接看板子丝印，确认是3.3V还是1.8V电平。之前有块板子是1.8V电平，直接用3.3V的模块去怼，结果串口芯片烧了，板子直接变砖，这个教训非常深刻。
注意：如果你的开发板丝印上没有明确标注调试串口，一定要先查原理图确认引脚定义，千万不要拿杜邦线乱插。TTL串口的RX/TX接反不会烧板子，但输出乱码；电平不匹配则可能烧毁芯片。
其次，串口工具软件。Windows上我习惯用MobaXterm，因为它自带串口会话，支持日志高亮、自动滚动，比PuTTY好用了不知道多少倍。macOS/Linux下用minicom或者screen都行，但我个人更推荐minicom，因为它的配置文件管理清晰，不容易把参数搞乱。各大平台的工具列表和参数区别，我整理了一个表格，方便你对照：
| 平台 | 推荐工具 | 波特率设置 | 备注 |
|---|---|---|---|
| Windows | MobaXterm / PuTTY | 1500000 | OpenHarmony默认用1500000，不是115200，这里是个大坑 |
| macOS | minicom / screen | 1500000 | minicom的配置文件路径是/etc/minirc.*，注意权限 |
| Linux | minicom / picocom | 1500000 | 如果/dev/ttyUSB0没权限，先加用户到dialout组 |
2.2 OpenHarmony镜像烧录：搞懂引导链再刷机
在开始调试之前，你得先把系统跑起来。OpenHarmony的烧录方式和传统嵌入式Linux有一些区别。标准开发板通常通过烧录工具将整个镜像包写入存储介质，这些镜像包括引导程序（U-Boot或Bootloader）、内核（Kernel）、ramdisk和system镜像等。烧录后，开发板的启动顺序是：Bootloader -> Kernel -> init -> 系统服务。
这块我有一个建议：刚开始调试时，先不要用自己编译的镜像，直接用官方发布的dayu200标准镜像跑通一遍，确认“官方固件能启动”之后再折腾自己的代码。这样后续出问题，你才能很明确地判断是不是自己改动引入的。
x86电脑版OpenHarmony的烧录方式又有点不同。它本质上像装一个常规操作系统一样，U盘启动或者直接在硬盘上部署，引导用GRUB，内核是专门为x86编译的。如果你手头有闲置的迷你主机，不妨拿来试试。系统起来之后，串口不一定能很方便地看到日志，得靠hdc网络调试和系统日志文件来排查，这也是我后面要专门聊x86场景的原因。
2.3 开发者模式与USB调试：hdc的前置条件
hdc是OpenHarmony的调试桥工具，类似Android的adb。但要让它工作，你得先打开设备的开发者模式。在标准开发板上，通常需要在“设置 -> 关于 -> 版本号”里连点多次，或者在系统参数里开启开发者选项。在部分开发板上，这个选项在出厂固件里默认就是打开的，但为了保险，还是确认一遍比较好。
打开开发者模式后，还需要通过USB连接电脑，并在设备上授权“允许USB调试”。这一步骤和Android手机非常像。连接成功后，电脑终端输入hdc list targets，如果能看到设备序列号（一串字符），说明连接已经建立。这个环节看起来简单，但经常出问题，我在后面“常见问题速查”里整理了集中症状和对策。
3. 板斧一：串口终端，系统是否活着就看这里
3.1 串口输出的阶段拆解：从Bootloader到用户态
串口终端是OpenHarmony硬件调试的第一个观察窗口。接好线、打开终端，按下开发板复位键或重新上电，你会看到屏幕上刷出一大堆启动日志。对新手来说，这部分日志可能有点吓人，但其实内容是有阶段性的，搞清楚每个阶段在干什么，你就抓住了串口调试的命脉。
首先是Bootloader阶段。OpenHarmony在标准ARM开发板上用的是U-Boot，它会初始化DDR、加载内核镜像，打印的日志通常以U-Boot 2017.09或类似版本号开头。这个阶段如果卡住，说明Bootloader配置不对或者镜像有问题。其次是内核阶段，这里会打印大量Kernel日志，包括CPU信息、内存布局、设备树、驱动初始化等。内核阶段的日志末尾通常会挂载根文件系统，然后启动第一个用户态进程。最后是用户态阶段，init进程会启动各种系统服务，这个阶段串口上可能看不到太多输出，因为主要日志开始走hilog了。
我在调试一块RK3568开发板时，系统一直卡住无法进入用户态，串口最后的输出停在内核的某个驱动初始化位置。通过串口日志快速定位到是该驱动的电源域配置有问题，而不是去翻几十个系统服务日志，效率高了不止一个量级。所以看串口日志时，特别注意“停在哪一句”往往就是问题所在。
3.2 串口无输出的5个排查点
串口无输出是所有调试问题的起点，也是最磨人的问题。总结下来，99%的情况出在这5个环节。
- 接线错误：TX/RX接反、地线没接、杜邦线松动。这个最常见，先排除。
- 波特率不对：OpenHarmony默认1500000，如果工具里配成115200，屏幕上就是乱码或者完全没反应。
- 串口被占用：电脑上开了多个串口工具，或者USB转串口模块被其他程序占用，导致终端拿不到数据。
- 串口芯片驱动没装好：CP2102、CH340这类芯片在Windows下需要安装驱动，设备管理器里看到感叹号就是没装好。
- 板子没上电或复位没按：这看着像废话，但有时候你线接对了、参数也调好了，就是忘了给板子上电。
这几个点我建议做成一个检查清单，调试之前照着过一遍。实际踩坑经验是，新手60%的问题出在第1和第2项，老手偶尔也会在第4项上翻车——尤其是换了一台电脑，驱动忘了装。
3.3 串口日志的保存与分析技巧
调试时，光在终端上看日志是不行的，日志刷新太快，你想回翻某一段经常翻不到。正确的姿势是把日志从最开始就保存到文件。
MobaXterm下可以设置日志记录（Settings -> Terminal -> Logging），把串口会话的所有输出实时写入本地文件。使用minicom时，可以用Ctrl+A然后按L开启日志捕获。这样调试完，你就有一份完整的启动日志文件，可以用编辑器或日志分析工具慢慢搜关键字，比如搜索error、fail、panic等。我当时调试x86版OpenHarmony启动问题时，就是靠把串口日志全部存下来，然后按时间线逐段排查，才定位到某个AHCI驱动在特定主板上初始化超时。
另有一个小技巧：串口日志内容过长时，不要盲目从头看，优先看末尾最后50行的报错信息。内核启动日志的特点是，关键错误后面往往会跟着调用栈或驱动回滚信息，这些信息足以帮你定位到具体的模块。
3.4 常见串口调试问题速查
根据我自己的经验，把串口调试中比较常见的症状和根因做成了一张速查表，保存下来，能省不少折腾时间。
| 现象 | 可能原因 | 解决方向 |
|---|---|---|
| 完全没有字符输出 | 接线错误、串口占用、波特率不对、板子没上电 | 按前面5个点逐项检查 |
| 输出乱码 | 波特率不匹配 | 确认是1500000还是115200 |
| 只有第一行输出 | Bootloader阶段失败 | 检查Bootloader镜像、内存初始化配置 |
| 内核日志卡在某处 | 对应驱动初始化失败 | 查该驱动的设备树配置与内核选项 |
| 特定驱动报错但系统继续启动 | 非关键驱动失败 | 记录日志，后续通过日志定位 |
4. 板斧二：hilog日志，别再用printf排查问题
4.1 hilog和串口日志的分工逻辑
很多从Linux转过来的开发者，习惯了用printf往串口打日志。在OpenHarmony上，这个习惯得改改。OpenHarmony有一套独立的日志系统，叫hilog。它和内核日志是完全不同层面的东西：串口/内核日志主要负责启动阶段和内核态的调试，而hilog负责用户态系统服务和应用层的日志输出。
为什么要单独立一套日志系统？因为系统起来之后，用户态服务的日志量非常大，如果全部往串口上打，会严重拖慢系统响应，串口本身也会成为瓶颈。hilog会将日志写入内存缓冲区或日志文件，开发者可以通过hdc hilog命令按域、按级别、按进程名过滤查看，效率极高。
从使用感受上说，hilog和Android的logcat非常像，但也有一些差异。最明显的差异是域（domain）概念。OpenHarmony的日志会划分不同的域，比如系统能力域、应用域、驱动域等。日志格式通常是：时间、进程号、线程号、域、日志级别、标签（tag）、日志内容。看懂了这一行格式，你就能快速定位到日志来源是哪个模块。
4.2 hilog常用命令实战
使用hilog之前，先确认你的hdc已经连上了开发板。然后在电脑终端输入hdc hilog，即可实时查看设备日志。但直接裸跑hdc hilog日志量很大，关键信息会被淹没。我实际使用中，最常用的就是组合过滤命令。
第一，按级别过滤。比如只要错误和致命级别：hdc hilog -e只查看错误级别（ERROR）和致命级别（FATAL），hdc hilog -w只查看警告（WARN）及以上级别。这个能快速筛掉大量无用的info日志。第二，按标签或进程过滤。如果你知道某一个进程的名字，例如foundation或com.example.myapp，可以用hdc hilog -T [tag]按标签过滤。OpenHarmony的hilog命令和Android的logcat不完全一样，我更常用的是先用hdc shell进入设备终端，再用hilog -T xx查看某个具体标签的日志，这样更直观。第三，输出到文件。日志量太大时，可以先把日志拉到本地再分析：hdc shell "hilog -x > /data/log/hilog.txt"，然后通过hdc的file recv命令拉取到电脑。
4.3 日志级别与过滤参数的配置心得
很多应用开发者会遇到一个问题：在DevEco Studio里调试应用时，console.log的输出在哪看？通过hdc hilog的过滤，是能看到这些JS层日志的。但如果你在代码里使用了console.debug，默认级别可能不会输出到终端，因为hilog默认的显示级别是INFO及以上。这时候你可以用hdc hilog -D调整日志显示级别，或者直接在设备上改日志持久化级别配置文件。
这里有个关键点：hilog的日志级别分为DEBUG、INFO、WARN、ERROR、FATAL五级。默认显示级别通常是INFO，所以DEBUG级别的日志不会显示。你在做性能分析和逻辑追踪时，想在代码里加console.debug输出，结果发现终端里什么都没有，不要怀疑是代码没执行，先检查是不是日志级别过滤掉了。这个坑我踩过好几次，后来干脆统一用console.info以上的级别去打关键日志，DEBUG级别只留给临时调试用。
4.4 用两个终端配合，效率翻倍
实际调试过程中，我强烈建议开两个终端窗口。一个窗口串口保持连接，专门看内核日志和早期启动日志；另一个窗口用hdc连着，跑hdc hilog查看应用日志和服务日志。两个窗口同时滚动，信息互补。
我在调试系统服务启动崩溃时，就是这样操作的：串口窗口看到init进程启动某服务的痕迹，hilog窗口同时看到该服务报出的ERROR日志，两边时间一对照，立刻就能定位到崩溃点是在初始化流程的哪个阶段。如果只依赖其中一个窗口，你可能要反复试错好几次才能凑齐完整信息。
5. 板斧三：hdc调试桥，远程指挥开发的“双手”
5.1 hdc到底能干什么
如果说串口负责“看”，那么hdc就是“手”。你可以把它理解为OpenHarmony设备的远程控制通道，它可以在电脑上直接操作OpenHarmony设备，完成进程管理、文件传输、命令执行、日志查看、应用安装、崩溃抓取等操作。
hdc支持USB连接，也支持网络连接。USB连接适合ARM开发板，网络连接在x86电脑版OpenHarmony上几乎成了标配调试方式。hdc这个工具本体在OpenHarmony的SDK或官方工具目录里，Windows、Linux、macOS都有对应版本。配置好环境变量后，在终端输入hdc就能看到帮助文档。一个容易忽略的点是：hdc版本和设备端系统版本最好保持一致，否则可能出现协议不兼容导致无法连接。当年hdc协议有过几次更新，老版本的hdc连新系统连不上，新版本hdc连老系统也时有异常，这个一定要注意。
5.2 最常用的hdc命令组合
我把自己工作中使用频率最高的hdc命令整理成了一份清单，基本覆盖日常调试的各个场景。建议新手先把这些命令敲熟练，再慢慢探索其他功能。
| 命令 | 功能 | 使用场景 |
|---|---|---|
hdc list targets | 查看已连接的设备 | 确认设备是否连上、有没有驱动问题 |
hdc shell | 进入设备Shell | 在设备端直接执行命令 |
hdc shell ps -ef | 查看设备进程列表 | 确认某个服务进程是否存活 |
hdc file send | 本地文件发送到设备 | 推送可执行文件或配置文件到设备 |
hdc file recv | 设备文件拉取到本地 | 拉取日志、崩溃文件、截图文件 |
hdc hilog | 查看设备日志 | 过滤查看hilog日志 |
hdc install | 安装HAP应用 | 应用开发调试时安装包 |
hdc uninstall | 卸载HAP应用 | 卸载应用 |
hdc fport | 端口转发 | 将设备端口映射到电脑，方便网络调试 |
hdc shell reboot | 重启设备 | 调试后恢复状态或验证重启流程 |
举个例子，你写了一个C++ Native服务，编译好之后想放到板子上跑，就可以用hdc file send推到/data/local/tmp目录，再用hdc shell修改权限并执行。这套流程比反复烧镜像高效得多，是迭代开发的核心节奏。
5.3 x86电脑版OpenHarmony的hdc网络调试配置
这里专门说一下电脑版x86 OpenHarmony的hdc配置，因为最近很多人在折腾这个。x86电脑通常没有方便引出的调试串口，USB调试口也不像开发板那样固定，所以网络调试成了最实际的路子。
前提是x86电脑已经连上局域网，OpenHarmony系统已经正常启动。然后在电脑终端执行hdc tconn ip:port，这里的ip是设备的局域网IP，端口默认一般是8710。如果网络通、版本匹配，输入hdc list targets就能看到设备。用这个方式连接后，hdc shell、hdc hilog、hdc file send全都能用了。
网络调试的不稳定因素通常出在防火墙和IP地址变动上。建议在路由器上给设备绑定静态DHCP，或者在系统设置里配静态IP，避免每次重启后IP变化。另外，OpenHarmony系统本身的网络服务要正常启动，否则hdc tconn会一直显示连接超时。这时可以参考我们系列教程里网络配置相关的内容，先把系统网络调通。
5.4 hdc调试的常见问题
hdc调试也不是百分之百顺畅。除了版本不匹配，最常见的问题就是连接不上。
hdc list targets输出为空。先检查USB线缆和数据通道，建议用支持数据传输的USB线，不要用那种只能充电的线；再确认设备的开发者模式及USB调试权限是否已授权。- 连接USB时有设备但在Windows设备管理器里显示未知设备。通常是驱动问题，重新安装hdc配套的USB驱动解决。
hdc shell进去后经常掉线。可能是USB线质量差、接触不良，或者设备端USB服务不稳定。换一根短线通常能改善。- 网络连接时提示超时。可以用
ping测一下IP连通性，再用telnet ip 8710确认端口能不能通。端口不通就要检查设备端调试服务。
6. 实战案例：一块新板子从零开始跑通OpenHarmony
6.1 用三板斧排查系统启动失败
理论讲再多，不如来一次完整实战。假设我拿到一块全新的RK3568开发板，烧录了OpenHarmony标准镜像，但上电后系统起不来。我会严格按照三板斧的思路来排查。
第一步，连接串口，看到底卡在哪。串口日志显示内核已经启动，但最终在mount /vendor时失败，然后进入ramdisk的emergency模式。这一步说明Bootloader和内核镜像没问题，问题出在根文件系统挂载环节。第二步，进入串口的shell，手动检查/dev/block下有没有对应的vendor分区设备节点，再用lsblk或cat /proc/partitions确认分区是否正常。第三步，如果分区没问题，看/etc/fstab或对应的配置里分区挂载点是否写错。多半是镜像打包时分区表信息和实际烧录分区不对应。整个排查过程，串口提供线索，shell提供操作界面，日志提供细节。
这就是典型的“三板斧协同作战”范例：串口发现症状，shell确认状态，日志定位细节。三者配合，不用示波器也能八九不离十地找出问题。
6.2 x86电脑版OpenHarmony的启动调试实录
再看一个x86电脑版OpenHarmony的启动调试场景。我手头一台迷你主机，装好x86版OpenHarmony后，第一次开机卡在OpenHarmony的启动动画，无法进入桌面。
由于这台机器没有引出串口，我先尝试网络hdc连接，但系统没完全起来，网络服务可能也没启动，连不上。这种情况下我选择外接显示器和键盘，用本地console观察系统输出。OpenHarmony启动到图形界面之前，会有一段时间的内核启动日志显示在屏幕上，按Ctrl+Alt+F1（部分版本可能用其他组合键）可以切换到虚拟终端，看到console输出和shell提示符。通过这个方式，我能看到系统其实卡在某个驱动初始化阶段，日志提示和显卡驱动有关。于是我在启动参数里加入nomodeset，绕过显卡驱动初始化，系统就能继续启动了。虽然图形界面会有一些功能缺失，但至少系统可用了，后续再通过hdc安装对应驱动。
这个案例说明了x86调试的特殊性：串口不响，我们就用显示器和键盘；hdc不通，我们就想办法先让系统跑起来，再开网络调试。工具是死的，思路是活的。
7. 高频问题排查技巧与独家避坑经验
7.1 问题排查速查表
为了让你在真正遇到问题时能快速对照，我把这些年高频遇到的问题汇总成了一张速查表。表里没有写太细节的原理，都是直接能用的操作方向。
| 问题 | 可能原因 | 速查命令/操作 |
|---|---|---|
| 系统启动后无法进入桌面 | 图形驱动初始化失败 | 启动参数加nomodeset，或更换内核参数 |
| hdc连不上设备 | 开发者模式未开、USB线不支持数据、版本不匹配 | hdc list targets逐项排查 |
| hilog看不到应用日志 | 日志级别过滤、应用日志走JS层console级别低 | hdc hilog -D调级别，或检查代码日志级别 |
| 应用安装失败 | HAP包签名问题、系统API版本不兼容 | hdc install看报错信息，确认包和系统版本匹配 |
| 系统频繁重启 | 关键服务崩溃触发重启机制 | 串口和hilog配合，找crash堆栈 |
| 网络不通 | 网卡驱动未加载、IP配置错误 | hdc shell ifconfig或串口查看网络服务日志 |
| 某个传感器无数据 | 驱动加载失败、设备节点权限不足 | 串口查内核驱动日志，ls -l /dev看节点权限 |
7.2 独家避坑技巧：三板斧之外的3个习惯
我见过太多开发者在调试上卡很久，最后发现都是小问题。平时养成下面3个习惯，可以省掉大半的调试时间。
第一个习惯是保留复现现场日志。遇到问题第一时间把串口日志、hilog日志全部存档，标注时间点和操作步骤。很多时候你以为是玄学问题，回头看日志才发现是某个操作的必然结果。所有“偶发”问题，基本都是日志没抓全。
第二个习惯是学会二分定位。不要指望一次就能看到正确的日志。遇到启动失败，先看最后50行日志；遇到应用崩溃，先看crash堆栈前几行；遇到驱动无响应，先确认设备节点在不在。把问题范围先缩小到某一层，再逐步展开。这是硬件调试最核心的思维方式。
第三个习惯是不要盲目重刷系统。重刷是最终手段，不是首选调试手段。每次重刷都会丢失现场信息，特别是内核崩溃后的内存转储信息。我调试一个内核panic问题时，连续几次重刷系统，以为自己代码有bug，最后才发现是某次烧录时分区表写错导致的。如果当时不急着重刷，先保留一个崩溃现场，这个问题能早两天定位。
8. 从三板斧到调试体系的进阶路径
8.1 三板斧之后，下一步学什么
当你把串口、hilog、hdc都玩得比较溜，就会发现它们解决的是“能不能跑、跑得对不对”的问题，但还无法回答“跑得稳不稳、快不快”的问题。这时候就需要引入更高级的调试手段。
一个方向是性能分析。OpenHarmony系统里有perf、hiperf之类的性能剖析工具，可以统计CPU占用、函数热点、内存分配情况。另一个方向是崩溃栈分析，hdc可以抓取应用崩溃的调用栈信息，结合符号表反解出代码行号。还有一个方向是内核调试，如果你在做内核和驱动开发，学会使用内核的动态调试（dynamic debug）和ftrace，效率会大幅提升。x86环境下还有一个优势，就是可以接JTAG调试器，对内核做单步调试，这是ARM开发板不太容易实现的。
我的建议是：先把三板斧练到不需要动脑就能用的程度，再去学工具链。工具再高级，基础调试思维没建立，照样玩不转。
8.2 如何利用社区与官方资源加速成长
OpenHarmony的生态还在快速生长中，很多坑大家都会踩，多逛逛技术社区、看看别人的调试记录，能避开不少弯路。我自己的习惯是：遇到问题先在官方文档查找对应模块的调试说明，再去社区搜索有没有人遇到类似现象，最后实在不行才按三板斧的思路自己硬啃。社区资源里，最值得关注的是各家开发板厂商提供的BSP包、补丁说明和已知问题列表。比如有些开发板适配OpenHarmony时会有特定的内核补丁，如果你直接编译主线内核，就是起不来。这时候去查厂商适配记录，往往比埋头调试更有效。
x86电脑版OpenHarmony也一样，很多大神在社区分享了搭建步骤、驱动适配情况和启动参数调整的帖子，非常值得参考。不过参考别人的方案时，要注意版本差异，OpenHarmony迭代很快，半年前的帖子可能已经不完全适用了。
最后再说一点，做OpenHarmony开发，千万别怕折腾。硬件调试最迷人的地方就在于，每一次串口刷出日志、每一次hdc连上设备、每一次系统从崩溃边缘救回来，带来的成就感是纯软件调试给不了的。三板斧练熟了，后面遇到再大的问题，你心里也会有底气：无非是串口、日志、hdc三样，大不了慢慢查。这种解决问题的思路，也是我这些年在嵌入式上最大的收获。
