1. 为什么每个 Zephyr 开发者都得搞懂 west manifest做 Zephyr 开发的人几乎每天都在跟 west 打交道。不管你是刚在 Ubuntu 上搭好环境准备跑第一个 hello_world还是正在把 Zephyr 移植到某个 STM32F103 板卡上west build、west flash这些命令总是绕不开的。但很多人对 west 的理解停留在装依赖的工具这个层面真正遇到 manifest 相关的问题时——比如仓库拉不下来、版本不对、板级支持包找不到——就一脸懵了。说句实话west 本身不复杂它就是一个Python写的元工具真正复杂的是它背后的 manifest 机制。这个机制决定了你的工作区里有哪些仓库、每个仓库在哪个版本、仓库之间怎么关联。搞懂它你就能自由地管理自己的 Zephyr 工程结构而不是被样例工程绑死。这篇文章我打算把 west manifest 从原理到实操完整讲一遍包括 manifest 文件的结构、每个字段的含义、west init和west update到底做了什么、怎么自定义自己的 manifest 仓库、以及我在实际开发中踩过的坑。无论你是刚入门 Zephyr 的新手还是已经在做系统移植的开发者这篇文章应该都能帮你把 west manifest 这块拼图补完整。先提醒一下这篇文章不是简单的命令速查而是会深入讲清楚为什么。因为 west manifest 的设计理念其实很有意思它本质上是一个多仓库编排系统理解了设计意图之后即使遇到文档里没写过的情况你也能自己推导出正确做法。2. west 与 manifest 的关系先搞清楚工具和配置的分工2.1 west 是什么它解决什么问题Zephyr 这个项目非常庞大它不是单一仓库而是由很多个子仓库组成的。除了核心的 zephyr 仓库之外还有 hal硬件抽象层仓库、各种第三方模块仓库、以及每个厂商提供的板级支持包。如果手动去 git clone 这些仓库再把它们放到正确的位置配置好各自的版本工作量会非常惊人而且极易出错。west 就是 Zephyr 官方为了解决这个问题做的工具。它的名字来源于 Zephyr 的谐音风神设计目标是成为一个支持多仓库工作流的元工具。所谓元工具就是它本身不做编译、不做烧录而是通过调度命令去调用真正的工具——编译时调 CMake、烧录时调各个调试器工具链代码拉取时调 git。west 有两个核心功能维度一个是仓库管理另一个是命令分发。仓库管理就是通过 manifest 来定义工作区该有哪些仓库、该用哪个版本命令分发则是让用户可以在一个统一入口下执行各种构建和烧录操作。这篇文章的重点放在前者manifest 驱动的仓库管理。2.2 Manifest 就是仓库清单加依赖规则Manifest 这个词在英文里就是清单的意思。west manifest 本质上是一份 YAML 格式的清单文件里面列出了你的项目需要哪些 git 仓库、每个仓库从哪里拉取、切到什么版本、放到哪个目录。但不仅仅是清单这么简单。它同时还定义了仓库之间的依赖规则。比如你的应用工程依赖 zephyr 内核zephyr 内核又依赖某些 HAL 模块这些依赖关系都可以在 manifest 中体现。west 在 update 的时候会根据这些规则计算出正确的拉取顺序和版本组合。这有点像 package.json 之于 Node.jsrequirements.txt 之于 Python。但区别在于manifest 管理的不是语言层面的依赖包而是 git 仓库级别的依赖。这种设计是嵌入式项目特有的需求驱动的因为嵌入式项目中的依赖常常就是某个厂商的驱动仓库或者某个特定版本的硬件抽象层代码。2.3 West 的安装与工作区结构在开始讲 manifest 之前得先确保 west 装好了。在 Ubuntu 上安装 west 很简单用 pip 就行pip3 install westWindows 上装 Zephyr 也是同样命令只需要提前装好 Python 3.8 以上版本并加入 PATH。装完以后检查版本west --versionwest 引出了一个重要概念workspace工作区。一个 workspace 是一个顶层目录里面包含一个.west隐藏文件夹和若干个仓库目录。.west文件夹中有一个config文件记录了 workspace 的基本配置还有一个topdir文件指向 workspace 的根目录。典型的 workspace 结构如下my-zephyr-project/ ├── .west/ │ └── config ├── zephyr/ ├── bootloader/ ├── modules/ │ └── hal/ │ └── stm32/ └── app/其中zephyr、bootloader、modules/hal/stm32这些目录都是根据 manifest 文件拉取下来的仓库。app是你自己的应用代码。这种结构的好处是所有相关代码都集中在一个 workspace 内而且通过 manifest 可以精确控制每个仓库的版本保证了团队协作时环境的一致性。3. 详解 manifest 文件从结构到每个字段的含义3.1 Manifest 文件在哪里找每个 west workspace 都会有一个 manifest 仓库。默认情况下这个 manifest 仓库就是 zephyr 仓库本身。在 zephyr 仓库的根目录下有一个west.yml文件这就是 Zephyr 官方维护的 manifest 文件。也有一种情况manifest 仓库可能是你自己维护的独立仓库不包含任何代码只包含这个west.yml。这种情况在企业内部项目中非常常见因为不同的产品线可能需要不同的仓库组合和版本锁定策略。不管 manifest 仓库是哪个它最终都会在 workspace 的.west/config文件中被记录下来。你可以随时查看这个文件cat .west/config输出大致是这样的[manifest] path zephyr file west.yml这里的path是 manifest 仓库所在的相对路径file是 manifest 文件的文件名。3.2 Manifest 文件的顶层结构打开 Zephyr 项目根目录下的west.yml会看到一个长这样的 YAML 结构manifest: version: 0.14 remotes: - name: zephyrproject-rtos url-base: https://github.com/zephyrproject-rtos defaults: remote: zephyrproject-rtos revision: main projects: - name: zephyr remote: zephyrproject-rtos revision: v3.5.0 path: zephyr west-commands: scripts/west-commands.yml - name: hal_stm32 revision: 9b6ec8a0f1e0d29a24a56b2b4f7d2d346f552d6 path: modules/hal/stm32 groups: - hal - name: mcuboot path: bootloader/mcuboot groups: - bootloader self: path: zephyr west-commands: scripts/west-commands.yml这个结构看起来简单但每个字段都有讲究。下面我逐个拆开讲。3.3 Remotes 和 Defaults定义仓库来源与默认值remotes定义了一组远程仓库的别名。每个 remote 有一个name和一个url-base。url-base是 URL 前缀后面在 projects 中定义具体仓库时只需要写仓库名west 会自动拼接成完整 URL。比如上面例子中URL 前缀是https://github.com/zephyrproject-rtos那么项目zephyr的完整 git 地址就是https://github.com/zephyrproject-rtos/zephyr.git。defaults的作用是设置默认值。这里的remote默认值是zephyrproject-rtos意味着所有 projects 在未显式指定 remote 的情况下都会使用这个 remote。revision默认值是main意味着如果某个 project 没有单独指定 revision就会跟踪远程仓库的 main 分支。这个设计很贴心。它避免了在每个 project 下面重复写 remote 和 revision让 manifest 文件保持简洁。但也要小心默认值可能导致你无意中使用了某个仓库的 main 分支这在做版本发布时是个隐患。后面讲版本管理的时候我会详细展开。3.4 Projects清单的主体projects是 manifest 的核心部分它是一个列表每个元素描述一个需要拉取的 git 仓库。常用的字段有name仓库名称必须唯一。remote指定使用哪个远程仓库定义若缺省则用 defaults 中的设置。url如果 remote 满足不了需求也可以直接写完整 URL。revision指定拉取的分支名、标签名或 commit SHA。path仓库在 workspace 中的存放路径。若缺省则默认使用 name 作为路径。west-commands该仓库中包含的 west 扩展命令文件路径。groups仓库所属的组可用于选择性拉取。submodules配置是否拉取该仓库的 git submodules。其中我认为最需要注意的就是revision和path。revision决定了代码版本path决定了代码位置这两个字段直接影响到编译能否成功。例如 Zephyr 的构建系统在编译时会检查modules/目录下的 HAL 仓库如果你的 hal_stm32 被拉到了错误的位置CMake 配置阶段就会报错找不到 HAL 模块。3.5 Self定义 manifest 仓库自身的属性self段描述的是 manifest 仓库自身的属性。最常用的两个字段是path和west-commands。path表示 manifest 仓库在 workspace 中应该放置的位置。比如 Zephyr 官方的 west.yml 中self: path: zephyr表示 manifest 仓库也就是 zephyr 仓库自己在工作区中被放在zephyr目录下。west-commands表示这个仓库中包含了哪些 west 扩展命令。Zephyr 仓库通过这个字段向 west 注册了build、flash、debug等常用命令。也就是说你在终端里输入west build时实际执行的是 zephyr 仓库中scripts/west-commands.yml里定义的命令。理解 self 段的意义在于你可以用它来定义自己的 manifest 仓库并为自己编写 west 扩展命令。这在企业内部工具链定制时很常用。3.6 Manifest 版本字段manifest: version字段用来声明该 manifest 文件使用的 schema 版本。这个字段不是必需的但最好写上。不同版本的 west 支持不同版本的 manifest schema如果不写 versionwest 会假设你用的是当前版本支持的旧版本语法可能会导致某些新特性不可用。Zephyr 官方从某个版本开始将 manifest version 定为0.14这个版本号对应 west 的某个功能里程碑。实际开发中我们通常跟着 Zephyr 官方走不太需要主动改这个字段。但如果你的开发环境 west 版本较新而 manifest 文件版本较旧west 也会自动做兼容处理通常不会有大问题。4. West Init 与 West Updatemanifest 的落地过程4.1 West Init 的两种模式west init是创建 workspace 的第一步。它的作用是根据指定的 manifest 仓库初始化 workspace 的结构。这里有两种模式需要区分。第一种刚刚接触 Zephyr 的人最熟悉的方式west init zephyrproject cd zephyrproject west update这条命令做的事情是创建一个名为zephyrproject的目录在其中克隆 zephyr 仓库同时生成.west配置目录并设置 manifest 仓库为 zephyr 本身。之后west update会根据 zephyr 仓库中的 west.yml 拉取所有其他依赖仓库。第二种方式是使用-m参数指定自己的 manifest 仓库west init -m https://github.com/your-org/your-manifest-repo.git my-workspace cd my-workspace west update这种模式适用于你有独立的 manifest 仓库时。比如公司内部维护了一个包含所有产品线的 manifest 仓库只需要 init 时指定地址workspace 就会按照这个 manifest 的定义来构建。我强烈建议在团队项目中使用这种方式因为独立 manifest 仓库让版本控制更加灵活你可以为不同版本的产品线创建不同的分支或 tag。还有一个常用的参数是--mr用来指定 manifest 仓库的 revision。比如west init -m https://github.com/your-org/your-manifest-repo.git --mr v1.2.0 my-workspace这样在 init 的时候就把 manifest 仓库切到了v1.2.0标签上确保后续 update 用的是这个版本的 manifest 定义。4.2 West Update 到底做了什么west update是实际拉取代码的命令。它会读取 manifest 文件解析 projects 列表然后依次执行 git 操作。根据我的观察很多人对这个命令的原理不了解只知道输入了就有代码了。这里有必要讲一下过程。west update 对每个 project 的操作大致如下检查该 project 的path目录是否已存在。如果不存在clone 仓库到指定路径。如果已存在检查是否是一个 git 仓库以及它的remote和当前分支是否与 manifest 一致。根据revision字段执行 checkout 或 reset 到指定版本。如果该 project 配置了submodules还会递归更新 submodules。当出现代码拉取的怪异问题时比如本地代码被修改、分支不对、仓库没更新多半就是 update 过程中的某一步出了问题。后面我会专门讲这些问题的排查方法。这里要特别强调一个细节west update默认会强制执行git checkout到 manifest 指定的 revision如果你在本地修改了某个被管理仓库的代码并且这些修改没有提交update 可能会失败或导致修改丢失。所以最佳实践是不要在 west 管理的仓库里直接改代码要改就新开分支或者提交后再做其他操作。4.3 顶层目录的额外选项除了上面提到的基础字段west manifest 还支持给每个 project 配置topdir选项用来控制该仓库在 clone 时是否保持 git 仓库完整。这听起来有点抽象实际它的主要作用是控制 update 时是否执行git fetch。默认情况下west update 会执行 fetch 来获取远程的最新引用。但如果你把某个 project 的topdir设为falsewest 就不会对这个目录执行 fetch。这在某些需要保持仓库状态不变的情况下非常有用比如你想让一个仓库固定在本地某个 commit而不希望它被远程的引用干扰。不过说实话这个字段我在实际项目中很少用。它更多是给 Zephyr 自身的特殊机制用的。普通开发者在大多数情况下不需要动它。5. 版本管理策略revision 用分支还是固定 SHA5.1 Revision 支持哪些值Manifest 中每个 project 的revision字段可以填三种类型分支名比如main、v3.5-branch。使用分支名意味着每次west update都会尝试拉取该分支的最新代码。Tag 名比如v3.5.0、v2.7.0。Tag 是固定的拉取后不会变动。Commit SHA比如9b6ec8a0f1e0d29a24a56b2b4f7d2d346f552d6。这是最精确的锁定方式。三种方式各有用途选哪种取决于你的开发阶段和项目需求。5.2 我建议的开发与发布分离策略在开发阶段尤其是一个人独立开发或者小团队快速迭代时用分支名比较方便。因为每次 update 都能拿到最新的代码省去频繁去改 manifest 的麻烦。但这样做有风险上游如果更新了不兼容的接口你的代码可能会突然编译不过。在发布阶段或者需要多人协作并且强调可重现性时必须使用固定 SHA 或者 Tag。比如产品要出固件你总不希望同一个 manifest 在三天前和三天后拉出来的代码不同。固定 SHA 是最严格的锁定方式它保证每次 update 得到的代码版本完全一致。我个人的习惯是日常开发用一个本地分支在defaults里写revision: main方便跟踪上游但在打 tag 发布的时候把所有 projects 都改为固定的 commit SHA 或用版本标签。Zephyr 官方也是这么做的你去看 Zephyr 官方发布版本的 west.ymlrevision 都是指向 vX.Y.Z 这样的 tag。5.3 如何快速修改所有仓库的版本改 manifest 版本其实不用手动去编辑 west.yml 的每个条目。west 提供了一些辅助命令。比如查看当前仓库的实际状态west list这个命令会列出所有 project 的 name、revision 和 path。输出格式类似zephyr v3.5.0 zephyr hal_stm32 9b6ec8a modules/hal/stm32 mcuboot v2.1.0 bootloader/mcuboot如果你想临时切换某个仓库的分支来验证某个功能可以直接在仓库目录里操作 git然后再用west update切回 manifest 指定的版本。注意这是临时操作下次 update 会被重置。如果想把所有仓库统一切到某个 tag可以用 west 的manifest子命令。比如生成一份解析后的 manifestwest manifest --resolve这个命令会把默认的 remote、revision 等填充到每个 project 中输出一份完整的 YAML。你可以保存这份文件作为 lock 文件west manifest --resolve lock.yml这是保证可重现性的一个实用技巧。虽然 west 不像一些语言包管理器那样自动生成 lock 文件但你完全可以用west manifest --resolve自己生成一份并提交到 git 里存档。6. 二值化与分组groups 字段的高级用法6.1 Groups 是什么groups字段是 manifest 中一个相对高级的功能很多初学者甚至不知道它的存在。它允许你给 project 打上组标签然后在 update 时选择性拉取或忽略某些组。Zephyr 官方在 west.yml 中使用了groups来对仓库分组。例如- name: mcuboot path: bootloader/mcuboot groups: - bootloader - name: hal_stm32 path: modules/hal/stm32 groups: - hal这里mcuboot被归入bootloader组hal_stm32被归入hal组。默认情况下west 会拉取所有不在任何组或者组被启用的 project。6.2 按需过滤仓库这个功能在资源受限或者只需要部分模块的场景下非常有用。比如你只需要编译一个不依赖 bootloader 的应用可以在 update 时排除 bootloader 组west update --group-filter-bootloader--group-filter参数的规则是以-开头表示排除该组以开头表示强制包含该组。多个条件用逗号分隔。也可以先排除所有组再只启用需要的组。这个思路在做最小系统裁剪时很实用west update --group-filter-all,hal这条命令先排除所有组再只启用 hal 组最终拉取的仓库就只包含没有组标签的核心仓库和 hal 组的仓库。这样能有效减少不必要的代码下载尤其在网络环境受限时体验明显。6.3 自定义组的注意事项如果你在自己的 manifest 中定义组有几点要注意组名不能包含特殊字符建议只用字母、数字和下划线。被 excluded 的组如果被其他启用的组依赖west 会报错。所以分组时要想清楚依赖关系不能只顾着按功能切分。修改--group-filter只是影响本次 update 的拉取范围不会影响 manifest 文件本身。如果你想把某个组的默认状态改掉需要在 manifest 文件中用group-filter字段来定义默认行为。这个细节比较容易踩坑。我曾经遇到过一个问题某个组默认没有启用同事在 CI 里 update 之后发现少了几个库编译报错查了半天才发现是 group-filter 的问题。后来我们统一在 manifest 的defaults下定义了默认 filter才彻底解决。7. 自定义 Manifest创建你自己的仓库编排方案7.1 为什么要自定义 ManifestZephyr 官方提供的 west.yml 只是一个通用模板。真实的项目里往往有自己额外的代码仓库、内部的私有驱动库、定制的板级支持包等。这时候你需要自定义 manifest把这些仓库也纳入 west 管理。自定义 manifest 的好处有几个方面统一入口、版本锁定、自动化协作。团队成员只需要执行标准的west init -m xxx和west update就能得到完全一致的开发环境不需要每个人手动 clone 各种仓库。7.2 最小自定义 Manifest 示例假设你的项目包含三个部分zephyr 内核、一个内部的传感器驱动库、自己的应用代码。那么你的 manifest 仓库可以只包含一个 west.yml内容类似这样manifest: version: 0.14 remotes: - name: zephyrproject-rtos url-base: https://github.com/zephyrproject-rtos - name: my-company url-base: gitgithub.com:my-company defaults: remote: zephyrproject-rtos projects: - name: zephyr revision: v3.5.0 path: zephyr west-commands: scripts/west-commands.yml - name: my-sensor-driver remote: my-company revision: main path: modules/lib/my-sensor-driver self: path: app west-commands: scripts/west-commands.yml注意这里self的 path 是app意味着 manifest 仓库本身会被放到 workspace 的app目录下。这个目录下不仅可以放 west.yml还可以放你自己的应用源码、CMakeLists.txt、prj.conf 等。west 允许 manifest 仓库兼职做应用代码仓库这是一种很常见的组织方式。7.3 在自定义 Manifest 中使用 west-commandswest-commands是 west 的扩展机制。你可以把常用的操作封装成命令让团队所有人都通过同一个接口执行。Zephyr 仓库的scripts/west-commands.yml定义了大量 build 相关的命令。你自己也可以定义自己的命令比如一个用于生成版本号或者检查代码格式的命令。最简单的自定义命令就是一个 Python 脚本加一个 YAML 声明文件。在scripts/目录下建一个west-commands.yml内容如下west-commands: - file: scripts/my_commands.py commands: - name: check-format class: CheckFormat对应的my_commands.py实现CheckFormat类继承自west.commands.WestCommand实现do_add_parser和do_run方法。这个机制的好处是团队的工具链行为完全可控。你不需要让每个人都去记一堆脚本文档统一用west check-format就能完成格式检查。这对项目规范化的帮助非常大。7.4 私有仓库的访问配置自定义 manifest 经常会包含 GitHub 私有仓库或 GitLab 内部仓库。这时 URL 就不能用 HTTPS 了通常要用 SSH 形式比如gitgithub.com:my-company/my-repo.git。在 manifest 文件里每个 remote 的url-base可以不同。比如公开仓库用https://github.com/zephyrproject-rtos私有仓库用gitgithub.com:my-company。west 本身不关心你是 HTTPS 还是 SSH它只是把url-base和name拼接起来当作 git remote URL。但要提醒一下SSH 访问需要提前配置好密钥并且确保测试一下能通过 SSH 拉取代码。很多新手在 CI 环境里遇到私有仓库拉取失败的问题十有八九是 SSH key 没有配置到 CI 服务器上。8. 常见问题与排查技巧实录8.1 Manifest 解析错误表现运行west update时提示 YAML 解析失败或者 schema 校验不通过。原因一般是两种一是 YAML 语法错误比如缩进不对、多了个 Tab二是使用了当前 west 版本不支持的 manifest schema 字段。排查方式west manifest --validate这个命令专门用来校验 manifest 文件的正确性。它会读取当前 workspace 的 manifest 文件并输出校验结果。如果提示 schema 版本问题考虑升级 westpip3 install --upgrade west我自己曾遇到过因为 YAML 中的yes被解析成布尔值 true 导致的诡异问题。经验就是manifest 里的字符串字段尽量用引号括起来尤其像revision: yes这种值绝对不要裸写。8.2 Update 时某个仓库拉取失败表现west update中途报错提示某个仓库 clone 失败或 fetch 失败。排查步骤先看错误信息里是哪个仓库用west list定位名称和 URL。手动 git clone 试试确认网络或认证问题。在 manifest 所在目录执行git pull确认 manifest 仓库本身是最新的。常见原因包括URL 拼写错误、仓库不存在、私有仓库认证失败、网络超时。如果是网络问题考虑设置 git 的代理或者调整凭证有效期。8.3 编译时找不到模块或 HAL表现CMake 配置时报错说找不到某个模块路径比如modules/hal/stm32不存在。这种情况通常不是代码问题而是 workspace 不完整。先检查west update是否完整执行。如果之前用了--group-filter排除了某些组那可能就是你排掉了编译需要的模块。另外一种可能是路径不匹配。比如 Zephyr 构建系统期望 HAL 在modules/hal/stm32但你的 manifest 把path写成了modules/stm32那构建就会失败。修改 manifest 中的 path 即可。8.4 本地修改被覆盖表现你在某个仓库里改了代码执行west update后修改不见了。这是 west update 的正常行为它会把所有 project 恢复到 manifest 指定的 revision。要避免这个问题建议在仓库内创建自己的功能分支例如feature/my-change然后 push 到远程或者至少本地 commit。之后把 manifest 中的 revision 指向这个分支或 commit SHA就不用担心 update 时被覆盖了。如果你确实需要维护对某个仓库的本地补丁更正式的做法是用 Zephyr 的 module 机制或者维护一个 fork。直接改 west 管理的仓库在团队协作中很容易引发混乱。8.5 Manifest 与实际版本不一致有时你会遇到一个问题west update已经成功但代码版本看起来不对比如某个仓库的 commit 和 manifest 中写的 SHA 不一致。排查步骤是cd 那个仓库目录 git log -1 git status确认当前 HEAD 是否指向 manifest 中的 SHA。如果 git status 显示有未提交的修改或者处于 detached HEAD 状态都可能导致实际代码和预期不一致。注意一种特殊情况如果 manifest 中的 revision 指向的是一个分支名那么 update 后你处于该分支的最新提交而这个提交会随着时间变化。所以如果需要精确锁定版本revision 必须写 tag 或 SHA而不是分支名。8.6 多个 Workspace 切换的困惑有些人会同时维护多个 projects就会创建多个 workspace。这时最容易犯的错误是在错误的目录下执行 west 命令。west 命令必须在 workspace 根目录或包含 manifest 的仓库目录下执行否则会报错could not find a workspace。解决方法是进入 workspace 根目录再执行命令。如果经常需要切换也可以设置 shell alias 或者使用 direnv 之类的工具自动 cd。9. 实操心得几个值得养成的 west manifest 习惯做嵌入式开发这么多年Zephyr 也算折腾得不少最后分享几个我自己的实践经验。这些不是在官方文档里明确写的但用下来确实能省很多事。第一个建议是务必把 manifest 文件纳入版本控制并且每次改动都要提交。很多项目把 manifest 当成一个配置文件随意修改不记录结果出了问题根本不知道是谁什么时候改了 revision。Manifest 本质上是项目构建环境的一部分应该和代码一样走 code review 流程。第二个建议是使用west manifest --resolve定期生成 lock 文件。尤其是在发布阶段把锁定的完整 manifest 存档和固件一起归档。这样即使在几个月后需要重新出同样的固件版本也能精确重构出当时的代码环境。第三个建议是在 CI 里固定 west 的版本。west 本身还在持续更新不同版本对 manifest 的解析行为可能有细微差别。CI 构建时建议用 pip 锁定 west 版本pip3 install west1.2.0这样能减少很多因为工具版本不一致导致的诡异问题。第四个建议是遇到 manifest 相关问题先看.west/config确认当前 workspace 用的 manifest 仓库和文件路径。有时候你会发现自己在一个莫名其妙的 workspace 里所有命令行为都不符合预期就是这个原因。最后多利用groups和--group-filter来裁剪你的工作区。Zephyr 的完整仓库树下载下来还是挺大的尤其是各种 HAL 仓库加起来有几百 MB。如果你只做某一个平台的开发完全可以只拉取对应的 HAL其余的排除掉。这不仅节省磁盘空间也加快 update 速度。west manifest 这套机制刚接触时可能觉得有点绕但用熟了之后会发现它其实很优雅。它把多仓库的版本管理、项目依赖、团队协作这些复杂问题都收敛到了一个 YAML 文件里。理解了它你在 Zephyr 开发中遇到的很多疑难杂症其实都能追溯到 manifest 配置上。希望这篇文章能帮到你以后遇到 west 相关的问题至少知道该往哪个方向排查。