空结构体struct{}仅在map value、channel元素、切片底层数组中真正省空间；嵌入结构体或用指针反而可能因对齐干扰、gc开销而浪费内存，不是通用压缩方案。
空结构体 struct{} 确实不占内存（unsafe.Sizeof(struct{}{}) == 0），但它不是“往哪塞都省空间”的通用压缩工具——只在按元素分配的容器中才真正省，其他地方可能白忙活甚至更糟。
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
因为 struct{} 没有字面量简写形式，ch 是语法错误。
- 发送必须带右值：
ch - 接收端可忽略值：
，或显式接收：<code>_ := - 缓冲通道
make(chan struct{}, N)中，N可设为1e6甚至更大，底层不为每个元素分配内存；而make(chan bool, N)会真实分配N字节，可能引发 page fault - 关闭通道
close(ch)是更明确的“终止”语义，比发一个再收一个更推荐用于退出通知
嵌入 struct{} 到结构体里会不会增大体积？
总大小不变（unsafe.Sizeof 仍返回正确值），但它会影响字段偏移和对齐边界，尤其当它不在末尾时。
- 若
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{}，实际是坑？
最常踩的三个点：指针间接引用、接口值包装、嵌入到结构体末尾。
-
*struct{}本身是 8 字节指针，且指向的地址是全局&zerobase，但 GC 仍需扫描该指针，纯属冗余 - 把
struct{}赋给接口（如var i interface{} = struct{}{}），接口值会包含类型信息+数据指针，实际占用 16 字节（64 位系统），远超零成本预期 - 当
struct{}是结构体最后一个字段时，编译器可能插入填充以保证安全（防止指针悬空），反而增加总大小；这种对齐行为依赖具体字段排列和平台，不可预测
真正省空间的场景只有三个：map value、channel 元素、切片底层数组。其余地方用 struct{}，多数时候只是让代码更难懂，而非更高效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
