企业官网建设流程全解析

写嵌入式GUI的时候，你是不是也经常陷入这种尴尬：界面元素明明就摆在屏幕上，代码却怎么也摸不到它的对象指针。项目做得越大越容易遇到这种问题——页面控件几十个，业务逻辑一绕，某个label、按钮、滚轮是哪个函数里创建的根本记不清，当时又没把指针存好，临时想改个颜色、绑个事件、或者在回调里反查它的父容器，只能干瞪眼。

这篇文章就专门聊 LVGL v8 里的子控件对象获取：get_child 这一族 API 到底怎么用，索引序列和创建顺序是什么关系，什么场景下必须主动去"抠"子控件，以及我实际项目里踩过的几个坑。不管你是刚把屏幕跑起来的入门选手，还是从 v7 往 v8 迁移的老用户，下面这些东西应该都能直接用得上。

1. 先搞清 v8 的对象树：children 链表与索引语义

1.1 屏幕是根，控件是层层嵌套的一棵树

LVGL 里所有可见元素都是 lv_obj_t 对象，它们之间不是扁平的数组关系，而是一棵很标准的树。你可以把 lv_scr_act() 当前活动屏幕当作根节点，屏幕上创建的任何控件都是它的直接子节点；某个容器控件内部又可以去 create 它的子控件，比如 lv_btn_create(parent, NULL)，新按钮就自动挂到 parent 下面。

这个树结构是库自己维护的，不需要你手动写插入逻辑，每次调用创建函数时把父对象指针传对就行。而"子控件对象获取"，本质上就是在这棵树上做查询：从某个父节点出发，找到满足条件的子节点。所以树结构没理解对，后面所有 API 都会用得很别扭。

有个很多人一开始没意识到的点：控件一旦创建，它的 parent 和 child 关系就固定了，但控件本身在树中的位置是动态的。你可以用 lv_obj_set_parent(obj, new_parent) 把某个控件从原来的父节点挪到另一个容器下。这种操作在界面重布局时挺常见，挪完之后，原来的 children 列表和新的 children 列表都会同步更新。

理解了树之后再看 API，你会发现 LVGL 提供的获取函数并不多，但每一个的使用场景都分得很清楚。

1.2 get_child(0) 到底拿的是谁：v8 和 v7 正好相反

这是最容易翻车的地方，我当年从 v7 升 v8 的时候就在这里栽过。

v7 里子控件列表按创建时间先后排列，先创建的排前面，所以 lv_obj_get_child(parent, 0) 拿到的是最早创建的那个子控件，顺序非常直觉。到了 v8，这个顺序被反过来了：新创建的子控件会被插到 children 链表的头部，索引 0 指向的是最后创建、显示在最上层的那个子控件，索引越大对应的子控件创建时间越早。

这个反转乍看很反直觉，但库这么做是有逻辑的。v8 的绘制和事件命中都需要按 z-order 从上层往底层检查，把新创建的控件放到链表头部，get_child(0) 就能直接拿到最上层的那个，省掉一次遍历。视觉上后创建的控件本来就会盖在先创建的上面，索引 0 = 最上面的层，对应关系非常干净。

我建议从 v7 迁移过来的朋友，马上做一次全量自查：凡是之前用 get_child(parent, 0) 表示"最早创建的那个控件"的代码，v8 里语义已经完全不同了。最稳妥的办法是在屏幕上依次 create 两个不同背景色的 label，然后看看索引 0 到底拿的是哪个颜色，自己亲测一次比看十篇文档都管用。

1.3 和子控件获取相关的常用 API 一览

先把 v8 里这一族接口拉个清单，后面每个都会展开讲：

注意看，这里说的子控件都是直接子级，不是任意层级的后代。想拿"孙控件"必须自己递归往下走，或者一级一级 get_child，没有一站式接口。这一点后面踩坑章节会专门讲。

2. 核心 API 实战：get_child / get_child_cnt / get_child_id 的用法与边界

2.1 数量与索引配对：标准的遍历姿势

遍历一个容器下的所有子控件，是获取子控件最高频的用法。标准姿势长这样：

uint32_t cnt = lv_obj_get_child_cnt(parent); /* 注意：i 必须用 int32_t，不能用 uint32_t */ for (int32_t i = 0; i < (int32_t)cnt; i++) { lv_obj_t * child = lv_obj_get_child(parent, i); if (child == NULL) { continue; } /* 对 child 做点什么 */ lv_obj_set_style_bg_color(child, lv_color_hex(0x123456), 0); }

这里有两个细节，代码里看不出来，但实际跑起来能坑死你。

第一个是类型符号问题。lv_obj_get_child_cnt 返回的是 uint32_t，而 lv_obj_get_child 的索引参数是 int32_t。如果你写for (uint32_t i = 0; i < cnt; i++)，然后 i-- 之类的操作，一旦 i 变成 0 再减一次，直接就回绕成 0xFFFFFFFF，for 循环变成死循环。我的习惯是循环变量一律用 int32_t，比较的时候再转一次，看着啰嗦，但能避免这类隐蔽问题。

第二个是索引语义。前面说了，v8 里索引 0 是最新创建的子控件，索引越大越早创建。所以上面这个循环打印出来的子控件顺序，和你在屏幕上看到的"从上到下"层级是倒着的。如果你想让遍历顺序和视觉顺序一致，更符合直觉的写法是从cnt - 1往 0 倒着走：

for (int32_t i = (int32_t)cnt - 1; i >= 0; i--) { lv_obj_t * child = lv_obj_get_child(parent, i); /* 这时候 i 从大到小，对应的控件从底层往顶层遍历 */ }

这个倒序遍历不仅是习惯问题，在"边遍历边删除"的场景里还是保命写法，后面会详细讲。

2.2 负数索引、空对象和 NULL 返回的处理

v8 的 lv_obj_get_child 支持负数索引。实现逻辑是：如果传入的 id 是负数，就先把它加上当前子控件总数，然后从头开始数。换句话说，-1 表示"最早创建的那个子控件"，它和lv_obj_get_child(parent, cnt - 1)等价。

这个负数索引我在实际项目里用得不多，但有一个常见误区：有人以为-1是"最后一个子控件"，在 v8 里这恰好是反的，最后一个子节点（索引 0）反而是最新创建的。如果你是从其他 GUI 框架转过来的，脑子里那套"索引越大越新"的经验，在 v8 这里完全失效。

再看空指针问题。lv_obj_get_child 在两种情况下会返回 NULL：一种是父对象的直接子控件数量为 0，另一种是传入的父对象本身就不合法。LVGL 内部其实在不少入口上做了参数检查，但它不会替你做业务判断，所以遍历时加上if (child == NULL) continue;是基本素养。

还有一类隐藏问题：当父子关系中父对象正在被删除或已经删除，子控件指针就变成了悬垂指针，这时候再用它会直接触发 HardFault。v8 里有一个 lv_obj_is_valid 函数（v8.3 系列可用）可以判断对象是否仍然在对象树里，后面踩坑章节会展开讲。

2.3 反向定位：get_child_id 的使用场景

有从父拿子，就有从子找父。lv_obj_get_child_id(child) 返回的是 child 在它的父节点 children 列表中的索引值，配合 lv_obj_get_parent 一起用，可以在事件回调里非常优雅地判断"当前点击的是容器里的第几个元素"。

static void item_click_cb(lv_event_t * e) { lv_obj_t * target = lv_event_get_target(e); lv_obj_t * parent = lv_obj_get_parent(target); int32_t id = lv_obj_get_child_id(target); LV_LOG_USER("clicked child id = %d", (int)id); /* 根据 id 判断业务逻辑 */ if (id == 0) { /* 点击的是最新的那个子控件 */ } }

这里有一个业务层面的坑：get_child_id 返回的是"控件在树结构里的索引"，不是"业务编号"。如果你在创建控件时做了动态增删，索引会被打乱。比如你先创建了 5 个按钮，删掉了第 3 个，那么原来的第 4 个按钮索引就变成了 2。所以，get_child_id 适合用来做临时性的位置判断，不适合长久保存控件的身份标记。想稳定地标识一个控件，建议用 user_data 或者单独维护一个指针数组，这个后面高级玩法里讲。

3. 真正的需求场景：什么时候必须去"抠"子控件

3.1 统一批量修改容器内所有控件的样式

这是最常见的需求。做一个设置页，十几个一样的按钮控件，你想把它们的背景色统一换掉。如果每个按钮都留一个全局变量，代码会被撑爆，而且毫无必要，一个循环全搞定。

static void change_btn_style(lv_obj_t * parent) { uint32_t cnt = lv_obj_get_child_cnt(parent); for (int32_t i = 0; i < (int32_t)cnt; i++) { lv_obj_t * child = lv_obj_get_child(parent, i); if (lv_obj_check_type(child, &lv_btn_class)) { lv_obj_set_style_bg_color(child, lv_color_hex(0x00AAFF), LV_STATE_DEFAULT); } } }

注意我加了 lv_obj_check_type 判断，这是个容易偷懒但很有必要的操作。如果父容器下面除了按钮还有 label 或者加载动画的 spinner，不加类型判断直接把所有子控件当按钮改样式，轻则显示错乱，重则类型不对应的属性直接无效甚至崩溃。v8 里 lv_obj_check_type 是标准 API，用来检查对象是否属于某个类（class），因为 v8 引入了基于类的对象系统，这个判断非常可靠。

3.2 动态创建按钮并批量挂事件回调

动态列表是嵌入式 UI 的常客：根据数据条数生成一行一行的按钮或面板，每行都要响应点击。创建的时候顺手把事件回调挂上去是最自然的，但如果你把创建逻辑封装成了函数，返回给外部的只有容器指针，那么循环获取子控件再挂回调就是唯一出路。

lv_obj_t * create_list(lv_obj_t * parent, int item_cnt) { lv_obj_t * list = lv_obj_create(parent); for (int i = 0; i < item_cnt; i++) { lv_obj_t * btn = lv_btn_create(list, NULL); lv_obj_t * label = lv_label_create(btn); lv_label_set_text_fmt(label, "Item %d", i); lv_obj_set_user_data(btn, (void *)(intptr_t)i); } return list; } /* 外部统一挂事件 */ lv_obj_t * list = create_list(scr, 8); uint32_t cnt = lv_obj_get_child_cnt(list); for (int32_t i = 0; i < (int32_t)cnt; i++) { lv_obj_t * btn = lv_obj_get_child(list, i); lv_obj_add_event_cb(btn, item_click_cb, LV_EVENT_CLICKED, NULL); }

回头在 item_click_cb 里用 lv_event_get_user_data 可以直接拿到那个按钮的业务编号，就不用去猜索引了。这比 get_child_id 稳定得多，因为 user_data 是控件创建时定的，后续增删不会改变它。

3.3 自绘复合控件时管理内部组件

做嵌入式设备的人基本都干过这种事：一个"卡片"控件，内部是一个背景容器、一个标题 label、一个数值 label、可能还有一个图标。你把创建逻辑封装成了 create_card()，返回给外部的是 card 对象，但外部业务代码可能随时需要改数值 label 的内容。

这种情况下，内部 label 指针没有暴露出来，外部就只有用 get_child 按位置去猜：假设背景容器是索引 0、标题是 1、数值是 2，然后写lv_obj_get_child(card, 2)。这个方案一旦内部结构调整，外部代码就静默失效，非常脆弱。

我的建议是：不要图省事把结构写成"用索引访问"的契约，而是用一个结构体把内部关键控件指针管理起来，哪怕结构体只维护在文件内部：

typedef struct { lv_obj_t * card; lv_obj_t * background; lv_obj_t * title_label; lv_obj_t * value_label; } card_t; lv_obj_t * create_card(lv_obj_t * parent, const char * title) { card_t * c = (card_t *)lv_mem_alloc(sizeof(card_t)); c->card = lv_obj_create(parent); c->background = lv_obj_create(c->card); c->title_label = lv_label_create(c->card); c->value_label = lv_label_create(c->card); lv_obj_set_user_data(c->card, c); return c->card; } /* 外部获取值 label */ lv_obj_t * get_card_value_label(lv_obj_t * card) { card_t * c = (card_t *)lv_obj_get_user_data(card); return c ? c->value_label : NULL; }

创建时就把指针存好，业务要用的时候通过 user_data 把结构体再拿回来，整个过程完全不依赖子控件索引。get_child 在复合控件场景里适合做通用兜底，但如果内部结构是你自己设计的，用结构体管理要可靠得多。

3.4 事件回调里通过 parent-child 关系反查归属

还有一种场景，事件回调触发了，但你拿到的 target 可能是一个深层子控件。比如你给某个容器绑定了 LV_EVENT_CLICKED，结果用户点的是容器里的一个 label，此时 lv_event_get_target 返回的是 label，不是容器。想判断"这个点击发生在哪个容器下"，就要一路往父级找。

static void container_click_cb(lv_event_t * e) { lv_obj_t * target = lv_event_get_target(e); lv_obj_t * scr = lv_scr_act(); /* 从 target 一直往上找到 screen，记录经过的每一层 */ lv_obj_t * iter = target; while (iter && iter != scr) { LV_LOG_USER("hit object type: %d", iter->class_p->name ? 0 : 0); // 打印对象信息，或者判断是否是你关心的那个容器 iter = lv_obj_get_parent(iter); } }

当然，如果树很深，这种逐级往上找的方式效率不差，因为层级一般不会很深。事件回调里结合 lv_obj_get_parent 和 lv_obj_get_child_id，还可以实现"点击列表中的某一项，知道它排第几"这种逻辑，非常实用。

4. 遍历子控件最容易翻车的四个位置：我的踩坑记录

4.1 边遍历边删除导致索引错位

这坑我踩过不止一次，而且每次都是线上运行好几天才被发现。

很多人写清理逻辑时会这样：

/* 错误示范：正序边遍历边删除 */ uint32_t cnt = lv_obj_get_child_cnt(parent); for (uint32_t i = 0; i < cnt; i++) { lv_obj_t * child = lv_obj_get_child(parent, i); lv_obj_del(child); /* 删除后索引前移，i 已经跳过了下一个节点 */ }

问题在于，lv_obj_del 删掉一个子控件后，children 链表会自动把后面的节点往前补位。索引 0 的删掉后，原来的索引 1 变成索引 0，此时循环里的 i 变成 1，等于跳过了原来索引 1、现在索引 0 的那个控件。后果就是界面上一个隔一个地残留控件，或者更严重的是越界。

正确做法有两个。第一个是倒序遍历：

int32_t cnt = (int32_t)lv_obj_get_child_cnt(parent); for (int32_t i = cnt - 1; i >= 0; i--) { lv_obj_t * child = lv_obj_get_child(parent, i); lv_obj_del(child); }

因为删除只影响比当前索引大的节点位置，倒着删的时候删掉一个，前面那些还没遍历到的索引不受影响，一次循环能删干净。

第二个做法是先收集指针，再统一删除：

#define MAX_DELETE 16 lv_obj_t * del_list[MAX_DELETE]; int del_cnt = 0; uint32_t cnt = lv_obj_get_child_cnt(parent); for (uint32_t i = 0; i < cnt; i++) { lv_obj_t * child = lv_obj_get_child(parent, i); if (need_delete(child)) { del_list[del_cnt++] = child; if (del_cnt >= MAX_DELETE) break; } } for (int j = 0; j < del_cnt; j++) { lv_obj_del(del_list[j]); }

这个方式在删除条件比较复杂、需要先做一轮判断的时候更安全，也避免了遍历过程中对象列表频繁变动。

4.2 空指针和延迟删除带来的悬垂引用

LVGL v8 里 lv_obj_del 的删除行为有一个很容易忽略的细节：如果你是在事件回调里删除了某个对象，它并不是立刻从内存里消失，而是被标记为"延迟删除"，等整个事件处理流程结束后才真正释放。这个机制本意是防止回调执行过程中对象被释放导致悬垂，但它会带来一个新的陷阱：回调里你删除了父控件，回调返回后，子控件指针依然"看似有效"。

我的经验是，凡是涉及跨函数传递 LVGL 对象指针，一定要在拿来使用前做一次有效性确认。v8.3 及之后的版本提供了 lv_obj_is_valid 函数：

if (lv_obj_is_valid(child)) { lv_obj_set_style_text_color(child, ...); }

注意这个 API 不是所有 v8 小版本都有，如果编译报错，说明你的版本不支持，那就只能靠设计来避免：在删除对象的那个模块里，把所有外部指针引用都切断，再调用删除。

还有一类空指针问题比较低级但很常见：创建控件失败。embedded 环境下内存可能不足，lv_obj_create 有一定概率返回 NULL，如果不对返回值判空就直接 get_child 或者 set_style，行踪飘忽的 HardFault 就这么来的。

4.3 孙子辈控件拿不到：跨级访问的陷阱

lv_obj_get_child 只能拿直接子级，这已经被无数人误用过。比如 label 里的文本样式、滚动条内部结构，或者某个容器里面的容器里面的按钮，你用lv_obj_get_child(parent, 0)拿到的是表层那个容器，而不是内部按钮。

我记得有个朋友调试一个"按钮文字改不了颜色"的问题，查了半天，原因是按钮下还有一个 label，他调用的对象层级是容器层，根本就不是那个 label，style 设置自然不生效。

正确的跨级方式是自己写递归，或者明确知道树的深度后逐层访问：

lv_obj_t * lv_obj_get_child_recursive(lv_obj_t * parent, int32_t idx) { lv_obj_t * direct = lv_obj_get_child(parent, idx); if (direct != NULL) { return direct; } /* 如果指定索引不是直接子级，也许你需要递归查找，需要定义更复杂的策略 */ return NULL; }

实际操作中，我更推荐使用"按类型 + 递归"的组合方式，而不是硬记深度。比如要拿到某个容器下的第一个 label，递归遍历时判断类型再返回，这样树的中间层级无论怎么调整，代码都不会失效。这类通用遍历封装，我在第 5 部分给了可以直接抄的模板。

4.4 索引顺序与 z-order：容易搞混的两套顺序

get_child 的索引顺序和视觉上的 z-order 顺序，很多人当成一回事，但它们只是强相关，不是完全相等。

v8 里子控件链表头部是最后创建的，绘制时越后创建的越靠上，所以索引 0 对应视觉最上层。这个规律在"创建后没有改过层级"的前提下是成立的，但如果你调用了 lv_obj_move_foreground() 或 lv_obj_move_background()，或者使用 lv_obj_move_to_index() 这类接口，控件在链表中的位置会被直接改动，此时"索引 0 = 最新创建"这个关系就被打破了。

我踩过的坑是这样的：界面上有一个弹窗，弹窗创建顺序比较晚，所以 get_child 索引 0 是弹窗背景层。我写了一段逻辑，假设索引 0 永远是弹窗，结果用户进行某些操作后弹窗被 lv_obj_move_background() 移到底层，索引 0 变成了主界面某个按钮，弹窗获取逻辑彻底失效。

真正确保 z-order 的方法是查控件状态标志，或者干脆在对象创建时用 user_data 打标签，而不是依赖索引推断层级。记住：索引反映的是 children 链表顺序，这个顺序受 move 系列 API 影响，不要把它当成不可变的业务约定。

5. 进阶封装：筛选指定类型、按 user_data 定位、递归遍历方案

5.1 用 lv_obj_check_type 做类型筛选

v8 里遍历容器时几乎必用类型判断，已经用到了。lv_obj_check_type 的用法有两种：

bool is_btn = lv_obj_check_type(child, &lv_btn_class); /* 基类判断：只要是按钮或其派生类都匹配 */ bool is_base_btn = lv_obj_has_class(child, &lv_btn_class);

两者区别在于，lv_obj_check_type 是精确匹配类型，lv_obj_has_class 是判断是否继承自某个类。实际写 UI 逻辑时，如果存在自定义的按钮子类，lv_obj_has_class 更实用，因为自定义按钮本质上也应该被当作按钮处理。

配合遍历，可以写出非常干净的代码：把一个容器下所有 label 找出来，把某个标签页下面所有 slider 找出来，再统一处理。这就避免了一个一个控件去手动标记，省下大量冗余代码。

5.2 用 user_data 给控件打业务标签

对象索引不稳定，类型筛选又只能区分控件种类，真正要为控件绑定业务含义，最合适的就是 user_data。v8 里每个 lv_obj_t 对象都可以挂一个 void* 的数据：

/* 创建时设置 */ lv_obj_set_user_data(btn, (void *)(intptr_t)item_index); /* 获取时读取 */ intptr_t idx = (intptr_t)lv_obj_get_user_data(btn);

两个细节值得说。第一，user_data 的类型是 void*，在 32 位 MCU 上和 int 宽度一致，直接存整数很方便；但在 64 位平台（比如跑 Linux 环境模拟器）上，int 是 32 位，void* 是 64 位，直接(void *)some_int会出问题。稳妥的做法是中间用 intptr_t 转一圈。

第二，如果你决定用 user_data 存结构体指针，注意结构体生命周期管理。user_data 本身不会被 LVGL 释放，如果这个结构体是你自己 malloc 的，必须在 lv_obj_del 之前手动 free，否则就是内存泄漏。我一般习惯在对象的 LV_EVENT_DELETE 回调里去释放 user_data 指向的内存，这样生命周期和控件绑定在一起。

5.3 深度优先递归遍历模板

既然 get_child 只能拿直接子级，做一个通用的递归遍历函数就是刚需。下面这个模板我用了很久，结构简单，可以直接复制进你的工程：

/* 深度优先遍历，对每个节点调用 cb */ static void ui_foreach(lv_obj_t * parent, void (*cb)(lv_obj_t * obj, void * ctx), void * ctx) { if (parent == NULL) { return; } /* 先处理当前节点的直接子级 */ uint32_t cnt = lv_obj_get_child_cnt(parent); for (int32_t i = 0; i < (int32_t)cnt; i++) { lv_obj_t * child = lv_obj_get_child(parent, i); if (child == NULL) { continue; } cb(child, ctx); ui_foreach(child, cb, ctx); } }

这个函数有几个使用注意点：

第一，cb 回调里不要直接删除 child。因为递归还会遍历它的子级，对象一旦删除，后续访问全部悬垂。真要边遍历边删，得把需要删除的对象收集到数组里，遍历完成后再统一删除，前面已经说过这个套路。

第二，遍历范围从"某个节点下"开始，不会往上跳出这个节点，很安全。如果你要遍历整个屏幕，入口传入 lv_scr_act() 即可。

第三，这个模板默认没有对当前节点本身执行 cb，因为"父容器自身"一般不归入"子控件"的业务逻辑。如果业务上需要连父节点一起处理，自己在第一次调用前先手动 cb(parent) 一次。

5.4 一个完整示例：批量改掉某个容器下所有 Label 的文本颜色

把上面几个技巧组装起来，就解决了很多实际需求。我前段时间在做一个数据展示面板（模拟项目X），界面上有大量动态创建的 label，文本颜色统一是深灰色。后来产品要求全部改成主题蓝色，逐个控件去改不现实，一个递归遍历全搞定：

#include "lvgl.h" static void change_label_color_cb(lv_obj_t * obj, void * ctx) { if (obj == NULL) { return; } if (lv_obj_check_type(obj, &lv_label_class)) { lv_obj_set_style_text_color(obj, *(lv_color_t *)ctx, 0); } } void ui_change_all_label_color(lv_obj_t * screen_or_container) { lv_color_t theme = lv_color_hex(0x0055FF); ui_foreach(screen_or_container, change_label_color_cb, &theme); }

这段代码的妙处在于，无论容器下面嵌套了几层，只要路径上能到达 label，就能命中，不用关心树的具体层次。

如果要更精细地只改"有特定业务含义"的 label，可以在创建 label 时给它打上 user_data 标签，然后在回调里判断 user_data 值再决定是否修改。这种做法避免了把业务含义写在控件类型里，也让遍历逻辑更加纯粹。

6. 版本迁移与升级检查：从 v7 到 v8 的差异清单

这部分专门写给正准备升级、或者已经升级但代码还在报奇奇怪怪 bug 的人。我见过太多人从 v7 工程往 v8 迁移时，卡在子控件获取这个看似不起眼的点上。

差异最大的就是 get_child 索引语义。v7 中索引 0 是第一个（最早创建）的子控件，v8 中索引 0 是最后一个（最新创建）的子控件。千万别觉得这是小事，我遇到过整整一个列表页的点击错位，最后定位到的问题就是这里：创建时列表项是按顺序创建的，业务上想点击最后一项（视觉最上层），但代码却拿的是 get_child(0)，在 v7 里拿到的是第一项，v8 里却变成了最后一项，逻辑正好反过来。

第二个差异是事件回调的 target。v7 时代，LV_EVENT_CLICKED 的 target 在不少情况下是整个容器，你需要手动用 lv_event_get_indev 去看点击位置。v8 会精确到被点中的最上层子控件，所以以前那套"拿到容器再去 get_child 判断是哪个子项"的老代码，在 v8 里 target 已经变细了，如果仍然按老逻辑再套一层 get_child，很容易找不到对象。

第三个差异是 v8 的类系统。v7 里判断一个控件是什么类型，靠的是 obj->type 枚举字段；v8 改成了 class 指针，所以child->type == LV_LABEL_TYPE这类代码在 v8 里已经不存在，必须用 lv_obj_check_type 或 lv_obj_has_class 完成类型判断。迁移工作量看着不大，但代码量一大就容易出现遗漏。

版本迁移这件事，我个人的建议是：先把所有涉及 get_child、get_child_cnt、get_child_id、parent-child 关系遍历的代码单独列一个清单，逐项核对语义变化；再把直接访问控件类型字段的代码全部替换为 class 判断 API。这两个动作做完，子控件相关的兼容问题基本能扫掉一大半。

7. 聊几句个人体会

文章写到这里，基本上把 lvgl_v8 获取子控件对象的用法、场景和坑都聊了一遍。最后分享几个我个人在实际项目里的使用习惯，算是给新朋友的参考。

创建控件时尽量把指针存进业务结构体，而不是创建完就扔。当时省下几个字节，后续排查问题可能要花几十倍时间。get_child 是补救手段，不是第一选择，能用结构体管好就别依赖索引。

必须用索引时，记得在 create 逻辑旁边写清"位置契约"。比如一个卡片容器里，背景是索引 0、标题 label 索引 1、数值 label 索引 2，就在创建代码边上用常量定义或者注释写明。不然两周后你自己回来看这段代码，真的会猜错。

做好封装。一个ui_foreach()递归函数，加上 user_data 打标签，能覆盖绝大多数子控件获取需求。不要到处散落 get_child 调用，把遍历逻辑收敛到函数里，维护成本会低很多。

接口行为以头文件注释为准。LVGL 不同小版本之间 API 细节可能有细微差异，我写这篇文章时验证的是我常用的 v8.3 系列，如果你用的版本更老或更新，花两分钟翻一下 lv_obj.h 里的注释，比我猜测要可靠。子控件获取是个细活，但把原理和边界条件搞清楚了，它也就是顺手的事。