为什么用 struct{} 而不用 bool 或 int 做占位符
因为 struct{} 占 0 字节，而任何其他类型（哪怕 bool）至少占 1 字节。在大量元素的集合（比如 map 的 value、channel 的消息体、切片元素）中，这个差异会直接放大成内存浪费。
常见错误现象：用 map[string]bool 存键存在性，但只关心“有没有”，不关心 true/false —— 这时 value 其实是冗余的；换成 map[string]struct{}，map 底层 bucket 里每个 value 就不占空间了。
-
struct{}是唯一大小为 0 的合法类型，unsafe.Sizeof(struct{}{}) == 0 - 不能取
&struct{}{}的地址（编译报错），但可以取变量的地址：var s struct{}; &s是合法的 - 所有
struct{}实例在内存中“共享同一块空地址”，但语言不保证这点，别依赖
struct{} 在 channel 中的实际写法和陷阱
用 chan struct{} 做信号通知最常见，但它不像 chan bool 那样能传语义信息，纯粹是“有事发生”这一事实本身。
使用场景：goroutine 间同步、退出通知、限流器令牌发放等不需要携带数据的轻量通信。
立即学习“go语言免费学习笔记（深入）”；
- 发送端必须用
ch ，不能省略字面量 —— <code>ch 语法错误 - 接收端可忽略值：
，或显式接收：<code>_<code> := - 别对
chan struct{}做缓冲区大小估算：虽然make(chan struct{}, N)合法，但 N=0 和 N=1000 的底层内存开销几乎一样（因为 value 不占空间），但逻辑上容易误读为“能存 N 个信号”
map 中用 struct{} 当 value 时的性能与写法细节
当只关心 key 是否存在，又不想让 map 存一堆无意义的 true，map[K]struct{} 是标准解法。
注意它和 map[K]bool 在写法上的关键差异：没有默认“真值”，每次插入都得显式赋值。
- 初始化：
m := make(map[string]struct{}) - 插入：
m["key"] = struct{}{}（不能写成m["key"] = {}） - 判断存在：
_, ok := m["key"]—— 和 bool 版本写法一致，但底层更省空间 - 删除：
delete(m, "key")，行为完全一样 - 别试图用
len(m)做性能敏感逻辑的依据：虽然长度准确，但 map 的实际内存占用仍取决于 bucket 数量，不是 key 数量
哪些地方不能用 struct{} 替代，容易踩坑
它不是万能的“零开销占位符”。有些场景看似能省空间，实则引入隐含成本或逻辑歧义。
- 不能作为结构体字段嵌入后还指望“继承方法”：
type T struct{ struct{} }合法，但T{}和struct{}{}是不同类型，不能互转 - 不能用于需要反射识别类型的上下文：比如某些 ORM 或序列化库会把
struct{}当作“空对象”跳过处理，导致字段丢失 - 数组或切片元素用
[]struct{}虽然省内存，但cap/len计算可能反直觉 ——make([]struct{}, 1000)分配的底层数组长度是 0 字节，但 slice header 本身仍要 24 字节（64 位系统） - 别为了“看起来更省内存”强行替换：如果代码可读性因此下降（比如别人第一眼看不懂
map[string]struct{}是干啥的），就得不偿失
真正省内存的地方，在于高频、大批量、生命周期长的容器；小范围、临时、低频的场景，用 bool 更直白，也无所谓那几个字节。
