struct{} 不占内存但使用需谨慎：地址可能相同或不同，值比较恒为 true；map[string]struct{} 是最佳 Set 实现；嵌入时 struct{} 应避免放在最后字段以防对齐填充；chan struct{} 通知需注意缓冲与关闭语义。
空结构体 struct{} 在 Go 中确实不占内存 —— unsafe.Sizeof(struct{}{}) 永远返回 0，但直接拿它“省空间”容易踩坑，尤其在结构体内嵌或高并发场景下。
为什么 struct{} 地址可能相同，也可能不同
Go 运行时用一个全局变量 zerobase 作为所有零大小对象的地址来源。局部栈上定义的多个 struct{} 变量（如 a, b := struct{}{}, struct{}{}）通常共享同一地址；但一旦发生逃逸（比如被取地址后传入函数、或作为 map value 被多次赋值），编译器可能为每个实例分配独立栈帧或堆空间，此时地址就不再相等。
- 逃逸判断可用
go build -gcflags="-m -l"观察 -
&a == &b不是语言保证，仅是常见实现优化，不可依赖 - 值比较
a == b永远为true，因为所有struct{}值语义相同
map[string]struct{} 是最安全的 Set 实现方式
相比 map[string]bool 或 map[string]int，用 struct{} 作 value 能明确表达“只关心 key 是否存在”，且避免布尔值带来的语义歧义（比如 false 是未设置还是显式设为 false？）。
- 内存节省真实：
bool占 1 字节，但受对齐影响实际可能占 8 字节；struct{}确保 0 字节 - GC 压力更低：value 不存任何数据，map 扩容/遍历时拷贝开销趋近于零
- 注意不要误写成
map[string]*struct{}—— 指针本身占 8 字节，还引入 nil 风险
嵌入 struct{} 到自定义结构体时的对齐陷阱
当 struct{} 出现在结构体**最后一个字段**时，Go 编译器会额外填充字节以满足对齐要求 —— 因为若后续有指针指向该字段，其地址必须落在结构体内存范围内，否则可能导致悬垂指针或 GC 不释放内存。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
type S struct { x int64; _ struct{} }→unsafe.Sizeof(S{})可能为 16 而非 8 - 安全写法：把
struct{}放前面或中间，如type S struct { _ struct{}; x int64 }→ 大小仍为 8 - 若只是想标记类型无关性，优先用命名类型
type signal struct{}，避免意外嵌入
chan struct{} 信号通道的典型误用
用 chan struct{} 做通知很常见，但容易忽略缓冲区与关闭语义的组合风险。
- 无缓冲通道（
make(chan struct{})）适合一对一同步，发送前必须有接收者等待，否则 goroutine 阻塞 - 带缓冲通道（
make(chan struct{}, N)）适合限流，但len(ch)返回的是已发送未接收数，不是“剩余容量” -
close(ch)后再发会 panic；但接收可继续直到 channel 空，这点和chan int一致 - 别用
select { case 等待关闭信号时漏掉 <code>default，否则可能永久阻塞
真正关键的不是“它不占内存”，而是它强制你思考：这个值是否真的需要携带信息？如果答案是否定的，struct{} 就是最诚实的类型选择 —— 但它的零内存优势，只在你没把它用错位置时才成立。
