看到下面的代码时，会感觉和常用的完全不一样：
import lvgl as lv
lv.init()
scr = lv.obj()
btn = lv.btn(scr)
btn.align(lv.ALIGN.CENTER, 0, 0)
label = lv.label(btn)
label.set_text("Hello World!")
lv.screen_load(scr)
难道不应该是：
import lvgl as lv
# 1. 初始化LVGL（这一步是对的）
lv.init()
# 2. 创建屏幕实例（父控件）
scr = lv.obj()
# 【核心错误】：试图通过Python属性赋值绑定子控件
# 仅在Python层给scr加了btn属性，C层无任何父子关联
scr.btn = lv.btn()
# 即使设置对齐，也因无父控件参考系而失效
scr.btn.align(lv.ALIGN.CENTER, 0, 0)
# 给按钮加标签（同样错误写法）
scr.btn.label = lv.label()
scr.btn.label.set_text("Hello World!")
# 加载屏幕
lv.screen_load(scr)
lv.btn(scr) 这种写法和平时的 Python 代码不一样，核心原因在于 LVGL 是 C 语言实现的嵌入式 GUI 库，其 Python 绑定优先适配底层硬件逻辑，而非单纯追求 Python 语法的 “优雅”。
LVGL 的核心逻辑由 C 语言编写，所有控件对应 C 层的 lv_obj_t 结构体，控件的层级关系本质是「父结构体的子节点链表挂载子结构体」。当你写 btn = lv.btn(scr) 时，并非单纯的 Python 代码调用，而是把 **scr 这个 Python 实例对应的 C 层 lv_obj_t 地址，传给 LVGL 的 lv_btn_create() 函数，让底层引擎在创建按钮的瞬间，就将其挂载到屏幕的子节点链表中。**
而如果用 scr.btn = lv.btn() 这种属性赋值，仅在 Python 层面给 scr 实例新增了一个属性，C 层的父控件链表完全没有变化，这个按钮会成为 “游离实例”：既不会被 LVGL 渲染引擎遍历绘制（引擎只处理有父节点的控件），也无法继承屏幕的坐标、样式规则，更实现不了 “移动屏幕带动按钮”“销毁屏幕释放按钮” 的核心逻辑。
并且，MicroPython 运行在 ESP32/STM32 这类微控制器上，RAM 往往只有几十 KB，**LVGL 的 Python 绑定是「薄封装」—— 尽可能减少 Python 层的额外开销。**如果封装成 scr.btn = lv.xxx，需要在 Python 层维护 “属性名 ↔ C 层控件地址” 的映射表，每次赋值都要触发额外的关联函数，这会增加内存占用和运行耗时，对于资源受限的嵌入式设备来说，这种开销是无法接受的。而 lv.btn(scr) 的写法直接对接 C 层 API，没有任何额外封装开销，是嵌入式场景下 “性能优先” 的必然选择。
并且，嵌入式 GUI 中，一个父控件往往有多个同类型子控件（比如屏幕上有 3 个按钮），如果用 scr.btn1 = lv.btn()、scr.btn2 = lv.btn() 这种属性赋值，不仅代码冗余，还无法动态管理子控件；而 lv.btn(scr) 配合 Python 列表就能灵活处理：
# 动态创建3个按钮并挂载到屏幕，底层C层链表同步更新
scr = lv.obj()
buttons = [lv.btn(scr) for _ in range(3)]
# 批量调整按钮位置
for i, btn in enumerate(buttons):
btn.align(lv.ALIGN.CENTER, 0, i*50) # 垂直排列3个按钮
这种写法既符合 Python 的容器管理逻辑，又能让 LVGL 底层正确记录所有子控件的层级关系，兼顾了灵活性和底层可控性。
例如，我们熟悉的 Python GUI 库（比如 tkinter）本质也是类似逻辑：
import tkinter as tk
root = tk.Tk() # 屏幕实例
btn = tk.Button(root) # 按钮挂载到屏幕，和lv.btn(scr)完全一致
只是 tkinter 是纯 Python 实现，底层会自动处理父控件关联，让你感觉不到 “显式传参” 的存在感；而 LVGL 因为 C 层的底层约束，把这种 “关联” 直接暴露为传参写法，本质逻辑是完全相通的。
