是的，map[string]struct{}比map[string]bool更省内存，但仅在value存储层节省，且仅对海量key才明显：struct{}的value被runtime跳过写入，不分配存储空间，而bool每个value占1字节加管理开销。
map[string]struct{} 真的比 map[string]bool 更省内存？
是的，但只在 value 层省，且只对海量 key 有意义。底层 runtime 对 struct{} 的 value 做了特殊跳过：不分配存储空间、不写入 bucket 数据区；而 bool 每个 value 固定占 1 字节 + runtime 管理开销（如 hash、tophash 等）。
容易踩的坑：
-
map[string]*struct{}完全抵消优势——指针本身 8 字节，还触发 GC 扫描 - 插入必须写成
m["key"] = struct{}{}，不能简写为m["key"] = {}（语法错误） -
len(m)和bool版本一样返回 key 数量，但底层 bucket 内存仍由哈希分布决定，不是线性增长
chan struct{} 发送信号时为什么总报错？
常见错误是写 ch —— 这是语法错误。Go 要求发送操作右侧必须有值，而 <code>struct{} 没有字面量简写形式，不能像 int 那样默认为 0。
正确写法只有两种：
- 发送：
ch - 接收端可忽略值：
，或显式接收：<code>_ :=
缓冲通道 make(chan struct{}, N) 中，N 可设为 1e6 甚至更大——底层不为每个元素分配内存；而 make(chan bool, N) 会真实分配 N 字节，可能引发 page fault。
嵌入 struct{} 到结构体里会不会增大体积？
不会增加总大小（unsafe.Sizeof 仍返回正确值），但它会影响字段偏移和对齐边界，尤其当它不在末尾时。
例如：type T struct { x int64; _ struct{}; y int32 } 中，y 的起始偏移被卡在 x 结束处（offset=8），而不是按 int32 自然对齐到 offset=12。这看似省了填充，实则可能破坏紧凑布局。
更隐蔽的问题：
- 不能对
struct{}字段取地址：&s._编译报错cannot take address of s._ - 别把它当“注释字段”滥用——语义不清，某些 JSON 库直接跳过该字段，反射行为也不一致
空结构体作为方法接收器时要注意什么？
用 type Logger struct{} + func (l *Logger) Info(...) 是安全的零内存方案，但前提是这个类型真不需要状态。一旦后续加字段，就得改接收器类型，破坏兼容性。
真正容易被忽略的是：所有 struct{} 实例共享同一地址（&runtime.zerobase），所以 == 比较地址可能返回 true，但这不是稳定契约——逃逸后地址可能不同。别依赖地址相等做逻辑判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
