空结构体 struct{} 真的不占内存吗？
是的，在绝大多数场景下，struct{} 占用 0 字节。Go 编译器会做特殊优化，让它的大小为 unsafe.Sizeof(struct{}{}) == 0。但要注意：这只是单个值的大小，不是所有使用场景都“免费”。
常见错误现象：var a [1000]struct{} 看似分配了 1000 个零字节，实际数组总大小仍是 0 —— 这没问题；但一旦放进 slice 或 map，行为就变了。
- 数组、字段、局部变量里的
struct{}确实零开销 - slice 元素类型是
struct{}时，make([]struct{}, N)分配的底层数据指针可能为nil（Go 1.21+ 更激进），但 len/cap 正常 - map 的 value 类型为
struct{}时，每个键仍需存储一个（空）value 占位符，不过 runtime 内部做了跳过写入的优化，不真写内存
用 struct{} 当 map 的 value 类型安全吗？
安全，而且是 Go 社区公认的“无值集合”惯用法，比如模拟 set： seen := make(map[string]struct{})。它比用 bool 更语义清晰，也比用 int 或指针更省内存。
关键点在于：map 插入 seen[key] = struct{}{} 不会引发内存分配，因为右值是字面量，且 value 类型无字段。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要写
seen[key] = *new(struct{})——new(struct{})返回*struct{}，解引用后虽等价，但多一次堆分配（哪怕很小） - 避免和
map[string]bool混用：后者在 range 中读取 value 是false（零值），而struct{}的零值不可打印，容易误判逻辑 - Go 1.22 开始，
range遍历map[K]struct{}的 value 会被编译器直接省略，连临时变量都不生成
chan struct{} 为什么比 chan bool 更轻量？
因为 channel 的缓冲区元素必须可寻址、可复制，而 struct{} 的零大小意味着：缓冲区底层不分配元素存储空间，仅维护头尾索引与锁。相比之下，chan bool 每个元素占 1 字节，缓冲区要真实分配内存。
典型使用场景是信号通知（如 goroutine 退出同步），此时你只关心“有没有”，不关心“是什么”。
- 发送
close(ch)或ch 均可唤醒接收方，但前者更明确表达“终止”语义 - 别用
chan *struct{}—— 指针有 8 字节（64 位），还引入 GC 跟踪开销，完全违背初衷 - 如果 channel 要带缓冲，
make(chan struct{}, N)的 N 可以极大（如 1e6），而make(chan bool, N)会真实分配 N 字节，可能触发 page fault
嵌入 struct{} 到其他结构体里会发生什么？
它不会增加外层结构体大小，但会影响字段对齐和内存布局 —— 尤其当它出现在非末尾位置时。Go 规定：空结构体字段不参与对齐计算，但会“占据”一个逻辑位置。
示例：type A struct { x int64; _ struct{}; y int32 } 中，_ struct{} 不改变 y 的偏移（仍在 16 字节处），但如果删掉它，y 可能被紧凑排布到 8 字节处。
- 嵌入
struct{}常用于标记接口实现（如type MyType struct{ struct{}; ... }），但注意：它不能替代interface{}或方法集控制 - 不要依赖空字段的地址：&a._ 可能 panic（Go 1.21+ 对部分零大小字段禁止取址）
- 多个连续的
struct{}字段会被合并处理，但混入其他字段后，行为变得难预测，建议只在末尾放一个作占位或文档用途
最易被忽略的一点：空结构体不是“什么都不做”的银弹。它在反射、序列化（如 json.Marshal）、方法集继承中仍有行为差异 —— 比如 json.Marshal(struct{}{}) 输出 {}，但 json.Marshal(&struct{}{}) 会报错 “json: unsupported type: *struct {}”。这些边界情况，得看具体用在哪条链路上。
