Go用结构体字段嵌入实现UI组件组合，需显式调用嵌入字段的Render()方法，按语义命名、区分值/指针类型，并拆分关注点以支持运行时配置切换。
Go 里怎么用嵌入实现 UI 组件的组合？
组合不是靠接口多态，而是靠结构体字段嵌入——这是 Go 实现“可定制布局”的最自然路径。你不需要抽象出 IComponent 或 Renderable 接口，直接让子组件作为字段嵌入父组件，就能复用方法、透传配置、控制渲染顺序。
常见错误是强行模仿其他语言的继承树，比如定义 type BaseLayout struct{} 再让 Grid 和 Flex 去嵌入它，结果发现字段冲突、初始化混乱、无法独立测试。
- 嵌入的是具体类型（如
Padding、Border），不是空接口或泛型约束 - 每个嵌入字段命名要语义化（如
padding Padding而非Padding），否则方法名冲突时编译器报错难定位 - 嵌入字段的
Render()方法不自动参与父组件逻辑，必须显式调用，比如l.padding.Render(w)
如何让布局组件支持运行时配置切换？
关键不是把所有样式参数塞进一个大结构体，而是按关注点拆分成小嵌入字段，并允许零值跳过渲染。比如边框、圆角、阴影这些视觉修饰，各自独立存在，不相互依赖。
典型陷阱是用一个 Style 字段统一管理所有样式，导致每次改个颜色都要构造新实例，且无法在编译期检查哪些样式被启用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个修饰组件（如
Shadow、Radius）实现自己的Render(io.Writer)，只在非零值时输出对应 HTML/CSS - 布局主结构体用指针字段（如
*Shadow）表示可选，避免零值误触发渲染 - 提供链式构造函数，例如
NewVStack().WithPadding(16).WithShadow(2)，内部只是设置对应字段指针
为什么不能直接在嵌入字段上调用 Render()？
因为 Go 的嵌入只是语法糖，不会自动代理方法调用到嵌入字段；如果你写了 type VStack struct{ Padding }，然后调用 v.Render()，那只会执行 VStack 自己定义的 Render，不会自动去调 Padding.Render()。
这和你期望的“组合即行为叠加”有落差，也是最容易卡住的地方：代码看着像组合，实际什么都没发生。
- 必须在父组件的
Render()方法里手动调度各嵌入字段的Render()，顺序决定 DOM 层级 - 如果嵌入字段是值类型（如
Padding），它的Render()接收Padding值拷贝，适合无状态修饰；如果是指针（如*Border），更适合需要共享状态或延迟初始化的场景 - 别忘了传入上下文参数（如
io.Writer或Renderer接口），不然所有Render()都只能打日志或 panic
嵌入太多字段会影响性能或内存吗？
只要字段本身不带大缓冲或 goroutine，嵌入几十个轻量修饰组件几乎没开销。Go 编译器对嵌入字段做内联优化，访问 v.padding.Left 和直接访问 v.Left 汇编指令几乎一样。
但容易被忽略的是：嵌入字段的初始化时机。如果某个字段（比如 AsyncLoader）在嵌入时就启动 goroutine，而你只是想把它当个可选装饰器，那就埋了泄漏隐患。
- 修饰类字段（
Padding、Margin）用值类型，零值安全，无副作用 - 行为类字段（
*Spinner、*Poller）用指针 + 显式Enable()方法，避免构造即启动 - 用
go vet检查是否有未使用的嵌入字段——它们可能是设计冗余，也可能是忘记调用
真正麻烦的从来不是怎么嵌入，而是怎么让每个嵌入字段知道自己该不该渲染、该在哪一刻开始工作、以及出错了往哪吐日志。这些边界条件，往往在第一个真实业务需求进来时才暴露。
