这次我们看一个嵌入式开源平台的组合：Nordic 芯片 + Zephyr 实时操作系统。它解决的不是“能不能点灯”的问题，而是从芯片底层的低功耗管理、蓝牙/Matter/蜂窝协议栈，到设备树配置、构建系统、固件升级、自动化测试全部拉通的一整套开发范式。如果你还停留在裸机标准库、传统 nRF5 SDK 或者 FreeRTOS 思路里，这篇内容值得认真看完。
先说结论：从行业采用率、开源社区活跃度和上游厂商参与度来看，Zephyr 是近几年发展最快的嵌入式开源 RTOS 之一。标题里提到的“十年深耕”，主要指 Nordic 从传统 nRF5 SDK 逐步转向基于 Zephyr 构建 nRF Connect SDK（NCS）之后，整个平台的能力边界被拉高了一个档位。现在 Nordic 从 nRF52 到 nRF53、nRF54，再到 nRF91 蜂窝系列，官方主推的开发路径已经全面落在 Zephyr 上，而不是某个私有内核上。
这篇文章会覆盖四块内容：第一，这套组合的核心能力与适用边界；第二，从零搭建 nRF Connect SDK 开发环境并完成一个工程的编译烧录；第三，通过实际测试验证串口日志、蓝牙功能、低功耗性能和自动化测试；第四，把工程里常见的坑和排查方法整理成清单，方便你直接对照使用。
1. 核心能力速览
在动手之前，先把这套平台的关键规格列清楚。下面这张表全部基于 Nordic + Zephyr 公开技术栈的通用能力，具体版本细节要以你安装的 SDK 为准。
| 能力项 | 说明 |
|---|---|
| 开源内核 | Zephyr RTOS，Linux 基金会托管，社区驱动开发 |
| 厂商 SDK | nRF Connect SDK（NCS），基于 Zephyr 封装 Nordic 芯片驱动和协议栈 |
| 支持芯片 | nRF52 系列、nRF53 系列、nRF54 系列、nRF91 蜂窝系列 |
| 支持架构 | ARM Cortex-M 为主，同时支持 RISC-V、x86、Xtensa 等多架构 |
| 主要功能 | 蓝牙 LE、蓝牙 Mesh、Thread、Matter、Zigbee、蜂窝 LTE-M/NB-IoT、低功耗管理、安全启动与 DFU |
| 硬件要求 | 一块 Nordic 开发板，或自研 nRF 目标板 + J-Link / nrfjprog 烧录器 |
| 开发环境 | Linux 推荐，Windows 推荐用 WSL2，macOS 也可用 |
| 配置系统 | Kconfig 做软件配置，Devicetree 做硬件配置，sysbuild 做多镜像构建 |
| 构建工具 | west + CMake + Ninja，GNU ARM 工具链编译 |
| 启动方式 | 命令行编译，west flash烧录，支持 J-Link、nrfjprog、pyOCD 等 runner |
| 接口能力 | Shell、RTT、串口日志；提供 Logging API、Sensor API、蓝牙 Host API 等 |
| 批量任务 | 支持west build多板级构建、twister自动化测试框架批量执行 |
| 适合场景 | 低功耗物联网设备、可穿戴设备、智能家居、工业传感器、蜂窝模块产品 |
从这张表可以看出，Zephyr 不是简单意义上的“又一个 RTOS”，而是一整套类似 Linux 开发体验的嵌入式软件平台。它把硬件描述、软件配置、协议栈、可信固件、测试工具全部放在同一套构建体系里，这是它和传统 RTOS 最大的区别。
2. 适用场景与使用边界
这套平台适合谁？先说适合的。
第一类是低功耗无线产品开发者。Nordic 的看家本领就是低功耗蓝牙，Zephyr 里的蓝牙协议栈已经非常成熟，从 Central、Peripheral 到 Mesh、Matter，官方 sample 可以直接基于真实芯片验证。第二类是智能家居设备厂商。Matter over Thread 和 Zigbee 的支持让 Nordic 芯片可以在同一套 SDK 下应对多种协议，不需要为每种协议维护独立代码基线。第三类是蜂窝物联网开发者，nRF91 系列配合 Zephyr 的蜂窝协议栈和 modem 驱动，可以快速做出 LTE-M/NB-IoT 终端。第四类是希望从裸机或传统 RTOS 迁移的嵌入式团队，Zephyr 的驱动框架和设备树模型跟 Linux 很像，Linux 背景的工程师上手会非常快。
不适合的场景也要讲清楚。如果你的产品只用到一颗简单 8 位 MCU，内存只有几 KB，代码量很小，Zephyr 的调度器、设备树、Kconfig 这套体系会显得略重，此时 FreeRTOS 或裸机反而是更务实的选型。如果你需要极致的实时性，纳秒级中断响应和严格的确定性调度，Zephyr 提供的是通用 RTOS 服务，你需要在任务优先级、中断嵌套和内核裁剪上下更多功夫。另外，Zephyr 的构建系统有学习曲线，west、CMake、设备树这一套组合，对于刚接触嵌入式的初学者来说，第一周会明显比用 Keil 点灯要慢。
涉及版权、隐私和安全的边界必须提一下。Zephyr 是开源许可证项目，商用不需要授权费，但你在工程里集成的第三方协议栈、加密库和示例代码，各有各的许可证要求，商用前要逐项核查。如果你做的是蓝牙设备或者蜂窝终端，产品要过认证，软件里涉及的射频参数、协议版本和加密算法必须按目标市场规范配置。低功耗蓝牙设备往往涉及个人数据收发，隐私设计要从前端通信模型就开始考虑，不能只靠加密库兜底。
3. 环境准备与前置条件
开发 Nordic + Zephyr，最怕的不是代码难写，而是环境不是一次搭对的。我把前置条件分成四块，你逐个核对。
3.1 操作系统与硬件
推荐用 Linux 进行开发，Ubuntu 22.04 或更新版本是社区最常用的环境。Windows 用户建议直接装 WSL2，然后在 WSL 里操作，避免原生 Windows 下面遇到 USB 与命令行工具的权限和路径兼容问题。macOS 也能用，但部分 Nordic 烧录工具对 macOS 的支持节奏会比 Linux 慢一些。
硬件方面，至少要有一块 Nordic 开发板，常见的是 nRF52840 DK、nRF5340 DK 或 nRF54L15 DK。如果没有官方开发板，也可以使用自研板，但要保证板上有 SWD 调试口，并且能识别 J-Link 或 DAPLink。
3.2 依赖工具链
以下是通用的工具链清单，具体版本号建议到 Nordic 官方文档或你使用的 NCS 版本对应页面确认。
- Python 3.8 以上，west 依赖 Python 环境
- CMake 3.20 以上
- Ninja 构建系统
- GNU ARM Embedded Toolchain，用于编译 ARM Cortex-M 目标
- nRF 命令行工具（nrfjprog、nrfutil），用于烧录和调试
- Git，用于拉取 NCS 仓库
如果你是 Ubuntu 环境，可以用以下命令先装系统级依赖。这里给的是通用模板，实际需要的包名以官方文档为准。
sudo apt update sudo apt install --no-install-recommends git cmake ninja-build gperf \ ccache dfu-util device-tree-compiler wget \ python3-dev python3-pip python3-setuptools python3-tk \ python3-wheel xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev3.3 磁盘与网络
Zephyr 源仓库和 NCS 仓库非常大，尤其是首次west update会拉取多个子仓库。磁盘建议至少预留 30GB 到 50GB 空间。网络方面，建议在网络比较稳定的时间段执行west update，否则容易出现子模块拉取超时。
3.4 配置检查
环境搭完之后，建议先跑一遍依赖检查。Zephyr 的构建系统会在编译时自动检查关键工具版本，但你自己也要手动确认一下：
python3 --version cmake --version ninja --version arm-none-eabi-gcc --version west --version如果你在 Windows + WSL2 环境，还要验证 USB 设备是否能在 WSL 里被 nrfjprog 识别。这一步最常用，也最容易出问题，后面排查章节会专门讲。
4. 安装部署与启动方式
这套开发栈没有图形化“双击启动”这个概念，所有操作都通过命令行完成。下面给的是最标准的 NCS 工作流，按步骤执行即可。
4.1 安装 west 工具
west 是 Zephyr 自带的构建和多仓库管理工具。先用 pip 安装：
pip3 install west如果你之前装过旧版 west，建议升级一下：
pip3 install --upgrade west4.2 初始化 nRF Connect SDK 工作区
创建一个工作目录，然后在目录下执行west init。注意这里用的是 nRF Connect SDK 的 manifest 仓库，不是纯 Zephyr 仓库。
mkdir ncs-workspace cd ncs-workspace west init -m https://github.com/nrfconnect/sdk-nrf .初始化完成后，再执行west update，这一步会按照 manifest 文件把 Zephyr、MCUboot、协议栈、驱动等几十个仓库全部同步到本地。
west updatewest update是第一次用时最容易卡住的地方。如果因为网络中断失败，可以重新执行一次，west 会断点续传，已经拉取过的仓库不会重复下载。
4.3 导出 Zephyr 构建辅助文件
接下来导出 CMake 包。这一步让构建系统能找到 Zephyr 内核和库：
west zephyr-export4.4 安装 Python 依赖
Zephyr 的很多脚本依赖额外的 Python 包，例如 pyelftools、packaging、pyyaml 等。官方通常会在 Zephyr 仓库里提供 requirements 文件：
pip3 install -r zephyr/scripts/requirements.txt如果你的系统 Python 环境受控，建议使用虚拟环境，避免污染系统 Python。
4.5 编译与烧录
环境配好后，从 sample 开始验证。以 nRF52840 DK 和 Zephyr 自带的 hello_world 为例：
cd ncs-workspace west build -b nrf52840dk_nrf52840 -d build/hello_world zephyr/samples/hello_world如果编译通过，烧录到开发板：
west flash -d build/hello_world这里说明一点：-b参数指定目标板卡名称，-d指定构建目录，最后一个参数是 sample 源码路径。不同的 Nordic 开发板，板卡名称不同，自研板需要自己在 SDK 里添加 board 定义，这是另一个主题，先不展开。
5. 功能测试与效果验证
工程能编译能烧录，只算环境没问题。要真正验证这套平台能不能用，建议按下面几个维度依次测试。
5.1 Hello World 与串口日志
先做最基础的串口输出验证。hello_world 样例默认会通过 UART 输出Hello World!，你需要用串口工具连接开发板的虚拟串口。
Linux 下段先看一下端口有没有出现：
dmesg | grep tty通常会出现类似/dev/ttyACM0的设备。然后使用串口工具连接，波特率常见为 115200：
screen /dev/ttyACM0 115200如果看到Hello World!输出，说明编译、烧录、UART 驱动、日志链路四层都是通的。这是整条工具链最可靠的地基验证，任何一层出问题都会在这里暴露。
判断标准：串口能稳定输出日志，拔掉 USB 重新插上后仍然能正常烧录和输出。
常见失败：串口设备不出现，多半是驱动问题或权限问题；输出乱码，说明波特率配置不对，需要和工程里的CONFIG_UART_BAUD_RATE匹配。
5.2 GPIO 与设备树验证
第二测，验证 GPIO 驱动和设备树配置是否生效。在 Zephyr 里，GPIO 引脚不是硬编码在代码里的，而是通过设备树描述。通常要创建或修改一个 overlay 文件，定义 LED 引脚：
/ { leds { compatible = "gpio-leds"; led0: led_0 { gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; label = "Green LED 0"; }; }; };然后在prj.conf里确认 GPIO 驱动已启用，或者直接用 sample 里的 blinky。编译烧录后，如果 LED 按预期闪烁，说明设备树解析、GPIO 驱动、时钟配置和板级初始化都是正常的。
这一步非常关键，因为 Zephyr 项目里大量问题都出在设备树节点名、标签、gpio 控制器引用和极性配置写错上，能在开发板上以最小代价验证，就不要等到画完板子再排查。
5.3 蓝牙功能验证
Nordic 的价值在于无线，所以蓝牙测试是必做项。用官方 peripheral_uart 或 throughput sample，编译烧录后，手机上用 nRF Connect 或 LightBlue 去扫描设备，应该能看到对应的广播名称。
测试时重点看三件事：第一，是否能在合理时间内扫描到设备；第二，连接是否稳定；第三，建立连接后能否正常收发数据。如果你用的开发板天线或匹配电路有问题，这个测试会直接暴露。
另外注意蓝牙协议栈的配置项，比如CONFIG_BT_CTLR_DATA_LENGTH_MAX、CONFIG_BT_CTLR_PHY这些会影响吞吐和连接稳定性。量产前不要用默认值不加验证。
5.4 低功耗与唤醒验证
低功耗是 Zephyr + Nordic 平台的重要卖点。测试低功耗不是简单的跑一个 sleep 示例，而是要看设备能不能进入目标睡眠模式，以及唤醒后系统状态是否正常。
Zephyr 里可以通过日志和电源管理 API 观察当前电源状态。比如pm_state_force()或系统电源管理的pm_state_get()，配合串口日志可以看到设备进入了什么状态。更实际的方法是外接电流计或使用 Nordic 的 Power Profiler Kit 测量平均电流。
判断标准：设备在空闲时进入深度睡眠，平均电流降到数据手册给出的预期范围；有外部事件或定时器事件时能快速唤醒并恢复运行。如果一直睡不下去，先查是否有 tickless idle 没开启，再查外设唤醒源是否注册成功。
5.5 功能验证汇总
| 测试项 | 输入方式 | 预期结果 | 验证点 |
|---|---|---|---|
| 串口日志 | 烧录 hello_world | 串口输出 Hello World | 编译、烧录、UART 驱动 |
| GPIO 控制 | 烧录 blinky | LED 闪烁 | 设备树、GPIO 驱动 |
| 蓝牙广播 | 烧录 BLE sample | 手机可扫描到设备 | 协议栈、射频链路 |
| 低功耗 | 空闲观察电流 | 电流进入预期睡眠值 | 电源管理配置、唤醒源 |
6. 接口 API 与自动化批量处理
Zephyr 不像 Web 服务那样提供一个 HTTP API，但它有自己的“接口”体系，而且自动化能力比很多人想象中强。如果你要构建连续集成或批量验证流程，这部分很关键。
6.1 日志与 Shell 接口
Zephyr 支持 Shell 子系统，通过串口或 RTT 输入命令，可以查看线程状态、设备树信息、内核对象，甚至动态切换日志等级。
启用 Shell 的方式是在prj.conf中开启：
CONFIG_SHELL=y CONFIG_SHELL_BACKEND_SERIAL=y CONFIG_LOG=y编译烧录后，通过串口输入kernel threads或devices就能看到系统内部状态。这相当于一个挂在嵌入式系统里的调试控制台，在验证驱动和排查死锁时非常有用。
6.2 RTT 接口与调试
SEGGER RTT 是另一种调试通道，比串口更快，不需要额外占用 UART 引脚。调试时先配置：
CONFIG_USE_SEGGER_RTT=y CONFIG_RTT_CONSOLE=y CONFIG_UART_CONSOLE=n然后用 J-Link RTT Viewer 连接，可以在非常低的开销下看日志和交互。RTT 在低功耗调试场景下尤其好用，因为不需要专门的物理串口，能减少对目标系统运行状态的干扰。
6.3 批量构建与自动化测试
Zephyr 提供了twister测试工具，可以批量构建和运行测试。它的作用是遍历所有支持的目标板和测试用例，然后并行执行构建与烧录测试。
# 在 Zephyr 仓库目录下执行 ./scripts/twister -T tests/drivers/uart -p nrf52840dk_nrf52840 -p nrf5340dk_nrf5340_cpuapp该参数的含义是：在指定板卡上运行 UART 驱动测试。twister 会为每个板卡组合生成独立的构建目录，并输出测试报告。放到 CI 里之后，每次代码合入前自动跑一轮编译和测试，能提前拦截大量回归问题。
6.4 批量烧录
量产阶段的批量烧录，可以通过west flash配合不同的 runner 完成，也可以用 nrfutil 脚本化处理。比如你需要把同一个固件烧到多块板卡上，可以在脚本里循环调用 nrfutil：
nrfutil dfu serial -pkg app.zip -p /dev/ttyACM0 -b 115200这种方式适合小批量生产和返修。大批量产线上通常会用专门的烧录器方案，但核心固件出包流程是一样的，先要生成带签名的 DFU 包，再交给产线工具烧录。
7. 资源占用与性能观察
Zephyr 的资源占用没有一个固定数字，它和 Kconfig 裁剪、协议栈选择、优化等级、日志等级强相关。但你要知道从哪里看，以及怎么看。
7.1 ROM 与 RAM 统计
编译完成后，构建工具会生成内存统计报告。查看方式：
west build -t ram_report west build -t rom_report执行后会在终端输出内存占用分布，并生成 HTML 报告。比如你可以看到蓝牙协议栈占了多少 ROM，mbedTLS 占了多少，线程栈占了多少 RAM。这个报告在优化代码体积时非常有用。
如果不能直接生成，也可以从编译日志里看Memory region Used Size Region Size %age Used这段，它给出 FLASH 和 RAM 的整体使用情况。这里不用对照任何“标准值”，你的产品规格会说清楚剩下多少资源。
7.2 影响资源占用的因素
影响最大的是 Kconfig 配置。CONFIG_BT、CONFIG_NVS、CONFIG_MCUMGR、CONFIG_LOG这些开关每开一个都会增加 ROM。日志等级设成 debug，也会明显增加代码体积和执行时间。设备树里启用的外设越多，驱动和中断处理占用的 RAM 越多，尤其是每个外设的缓冲区。
优化时建议按顺序排查：先关闭用不上的子系统，再把日志等级从 debug 调到 info 或 warning，然后检查是否有重复使能的驱动和传感器，最后检查线程栈大小，每个线程栈的默认值往往是偏保守的。
7.3 运行时性能观察
Zephyr 可以提供内核对象状态和时间统计。开启后，通过 shell 可以看到线程的堆栈使用情况、调度延迟和 CPU 占用。
CONFIG_THREAD_ANALYZER=y CONFIG_THREAD_ANALYZER_AUTO=y CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y这个特性在调低功耗或者排查任务卡死时价值很大。它能帮你看清哪个线程频繁唤醒，哪个线程栈深度不够，哪个线程占用了过多 CPU，避免靠猜。
7.4 功耗观察方法
功耗不是编译选项能直接测出来的，需要硬件测量。推荐用 Nordic Power Profiler Kit，或者简单的万用表串联到供电电路里看平均电流。观察时要特别注意：设备长时间空闲时有没有进入目标睡眠状态；有没有外设没被关掉，比如某个传感器在 sleep 模式还在吃电流；唤醒事件发生时，响应时间是否满足产品需求。日志本身也会影响功耗，频繁输出日志会让 CPU 频繁唤醒，所以在低功耗测量时，应该把日志关掉或调到最低等级。
8. 常见问题与排查方法
下面这是实际工程中最容易踩的坑，按现象整理成表格，方便直接对照。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
west update失败 | 网络不稳定、子模块地址变更 | 查看west update -v日志 | 重新执行west update，必要时使用代理或镜像仓库 |
| 编译报错找不到头文件 | 依赖仓库未完整拉取，或工具链路径错误 | 检查west list，确认 zephyr、nrf 仓库存在 | 重新执行west update，或重新设置ZEPHYR_TOOLCHAIN_VARIANT |
| 烧录时提示 No J-Link found | J-Link 驱动未装、USB 线不识别、板卡未上电 | 用nrfjprog --ids查看设备枚举 | 安装 nrf-command-line-tools，更换 USB 接口，重新插拔板卡 |
| 串口没有日志输出 | 串口号错误、波特率错误、串口权限不够 | 查看/dev/ttyACM*，检查dmesg | 用sudo usermod -aG dialout $USER添加用户权限，或使用 115200 波特率 |
| 日志输出乱码 | 波特率不匹配，或 UART 引脚被复用 | 核对prj.conf和实际串口连接 | 统一波特率，检查针脚配置与 USB 转串口对应关系 |
| Kconfig 改了没生效 | 构建目录缓存了旧配置 | 清理build目录 | 删除 build 目录后重新west build |
| 蓝牙扫描不到设备 | 天线引脚配置不正确、协议栈未启用、设备树射频节点未使能 | 检查日志，确认蓝牙初始化成功 | 对照官方板级设备树，检查高频晶振和天线匹配配置 |
| twister 批量测试卡住 | 板卡未连接，或者测试用例需要特定硬件 | 查看 twister 日志 | 按-p参数配置实际可用板卡，不要盲目跑全量 |
| 内存区域不足 | 启用了过多功能或设备树配置错误 | 查看west build -t rom_report | 裁剪 Kconfig 功能，优化日志等级，检查链接脚本 |
需要注意的是，Zephyr 的报错信息通常比较详细，但错误原因往往被前面的日志掩盖。比如说编译错误提示一个宏不存在，真正原因可能是CONFIG_SOMETHING没有使能。遇到问题先看完整日志，再看是哪一步失败，最后才去搜错误码。
9. 最佳实践与工程化建议
工程能跑起来是一回事，能稳定交付是另一回事。下面这些实践建议，来自长期使用 Zephyr 开发产品的通用经验，不是针对某个特定项目的专属技巧。
第一，项目目录结构要清晰。不要把所有 sample 代码堆在一起，建议一个产品一个目录，内部按src、include、boards、drivers、scripts组织，配置文件prj.conf、app.overlay、Kconfig各司其职。Zephyr 的构建系统对目录结构有默认约定，遵循约定比自创结构省心得多。
第二，Kconfig 配置不要全部放在prj.conf里。能用default写在 Kconfig 文件和驱动里的，就不要在应用层强制覆盖。否则后面换一个板卡，遇到同一个功能不同配置时，你会遇到大量冲突。合理使用prj_<board>.conf或boards/<board>.conf按板卡隔离差异配置。
第三，设备树 overlay 按时保留。用 devicetree 描述硬件时，建议把自定义硬件通过 overlay 文件放置，而不是直接修改 SDK 里的nrf52840dk_nrf52840.dts。这样 SDK 升级时不会丢改动，也可以同时维护多块自研板。每次改设备树后，用west build -t dtc检查生成的设备树是否符合预期。
第四，版本管理要做两层。第一层，应用代码必须纳入 Git 管理，并且把west update后生成的west.yml或west.lock提交到仓库，确保同事和 CI 能复现同一个 SDK 版本。第二层，不要轻易升级 NCS 版本，尤其是在产品验证阶段。每次 NCS 大版本升级，都意味着 Zephyr 版本的跳跃，驱动行为和子系统接口都可能变化，至少要留出一个月做迁移和回归测试。
第五，批量构建和测试要尽早接入 CI。Zephyr 生态里，twister已经是很成熟的测试框架。即使你的团队没有专职测试人员，至少在本地跑一遍twister -T tests/your_app_testsuite，能比手工测试多发现很多回归问题。
第六，信息安全要前置。Nordic 平台支持 TrustZone、MCUboot 和安全 DFU，产品从设计阶段就要考虑固件签名、安全启动、密钥管理和防回滚。不要等到量产前再补，否则密钥存储、加密分区和升级流程都可能要推倒重来。
第七，涉及第三方代码和样品代码的许可证要核对。Zephyr 和 NCS 的仓库里包含多个许可证的代码，有些 library 是 BSD、Apache 协议，有些可能是其他授权。商用前做一次许可证扫描，把合规风险提前解决，比事后补救成本低得多。
10. 总结与下一步
这套平台最值得尝试的点，是把嵌入式开发从“芯片手册 + 寄存器 + 私有 SDK”的模式，带到了“设备树 + Kconfig + 统一构建系统 + 可复用驱动框架”的模式。对比传统 RTOS，Zephyr 的工程代码在可复用性、可配置性和可调试性上有明显优势，同时仍然保持了低功耗硬件级设计的灵活性。
如果你刚开始接触 Nordic + Zephyr，第一步建议先跑通 hello_world 和串口日志，不要急着调蓝牙或低功耗。工具链通了，后面的协议栈、驱动、设备树这些模块就有稳定的验证基础，排查问题也会容易得多。最容易踩的坑基本集中在网络同步失败、串口权限、板卡名称不对这三类，前半个小时就能判断出问题在哪。
接下来你可以按自己的产品方向深入：做蓝牙设备，就去研究官方 peripheral_uart 和 HIDS 样例；做智能家居，就去跑 Matter over Thread 样例；做低功耗传感器，就重点验证 tickless idle、电源管理状态机和唤醒源配置；做蜂窝终端，就在 nRF91 系列上跑 modem 驱动的 TCP/IP 或 MQTT 样例。每一条路线都有对应的官方 sample 和配套文档，花点时间把基础链路走通，后面的开发效率会肉眼可见地提升。建议直接把这份环境搭建和验证流程存成团队的快速入门文档，后期换新成员或者换电脑时能少踩很多重复的坑。
