struct{}确实能省内存，但仅在map value、channel元素、切片底层数组等按元素分配的场景生效；嵌入结构体字段或使用指针反而可能引入对齐干扰或GC开销，不是万能省空间方案。
用 struct{} 确实能省内存，但只在 map value、channel 元素、切片底层数组这类按元素分配的场景生效；它不是“往哪塞都省”，嵌入结构体字段或取指针反而可能引入对齐干扰或 GC 开销。
map[string]struct{} 比 map[string]bool 真的更省内存？
是的，但节省只发生在 value 存储层，且仅当 key 数量极大时才明显：
-
map[string]bool每个 bucket 中 value 占 1 字节 + runtime 管理开销 -
map[string]struct{}的 value 部分被 runtime 特殊跳过写入，底层不分配存储空间 - 插入必须显式写：
m["key"] = struct{}{}，不能简写为m["key"] = {}（语法错误） -
len(m)返回 key 数量，和 bool 版本一致，但实际内存占用仍由哈希 bucket 分布决定，不是线性增长 - 别用
map[string]*struct{}——指针本身 8 字节，还触发 GC 扫描，完全抵消零大小优势
chan struct{} 发送信号时为什么不能写 ch<-？
因为 ch<- 是语法错误：channel 发送操作必须带右值，而 struct{} 没有字面量简写形式。
- 正确写法是：
ch <- struct{}{} - 接收端可忽略值：
<-ch，或显式接收：_ := <-ch - 缓冲通道
make(chan struct{}, N)中，N可设为1e6甚至更大，底层不为每个元素分配内存；而make(chan bool, N)会真实分配N字节，可能引发 page fault - 关闭通道
close(ch)是更明确的“终止”语义，比发送再接收更推荐用于退出通知
嵌入 struct{} 到结构体里会影响内存布局吗？
不会增加结构体总大小，但会影响字段偏移和对齐边界，尤其当它不在末尾时：
立即学习“go语言免费学习笔记（深入）”；
-
unsafe.Sizeof对含struct{}的结构体仍返回正确总字节数，该类型自身贡献为 0 - 若
struct{}出现在中间位置（如type T struct { x int64; _ struct{}; y int32 }），它会让编译器把y的起始偏移卡在x结束处（即 offset=8），而不是像普通byte那样触发 4 字节对齐调整 - 不能对结构体内的
struct{}字段取地址：&s._编译报错cannot take address of s._，因为它无独立存储位置 - 别把它当“注释字段”滥用——语义不清，还可能干扰反射或序列化逻辑（比如某些 JSON 库直接跳过
struct{}字段）
哪些地方看似能省空间，实则踩坑？
它不是万能膏药，有些用法反而引入隐性成本：
- 不能用
struct{}替代bool做标记位——它没有值语义，不能赋值、不能比较（除与自身或nil），只能用于存在性表达 - 别用
chan *struct{}或map[K]*struct{}：指针本身 8 字节，还引入 GC 跟踪开销 - 数组或切片元素用
[]struct{}虽然省内存，但make([]struct{}, N)的底层数据指针可能为nil（Go 1.21+ 更激进），注意 nil slice 的行为差异 - 反射或 ORM 场景下，
struct{}可能被当作“空对象”跳过处理，导致字段丢失
真正省下的，是那些按元素计数分配的场景；一旦涉及指针、接口值、嵌入字段或反射，就要重新权衡语义清晰度和潜在开销。
