map[string]struct{}比map[string]bool更省内存，因struct{}占0字节而bool占1字节（对齐后常8字节），百万key下后者多耗约8MB内存并加重GC压力。
map[string]struct{} 为什么比 map[string]bool 更省内存
因为 struct{} 占用 0 字节，而 bool 占用 1 字节（实际对齐后常为 8 字节）。百万级 key 的 map 中，后者额外吃掉约 8MB 内存，GC 压力明显上升。
实操建议：
- 声明集合类型时直接用
type Set map[string]struct{}，别图省事写map[string]bool -
struct{}作为 value 时，赋值写m[key] = struct{}{}，不是m[key] = {}（后者语法错误） - 注意：
map[string]struct{}无法通过len()直接判断是否为空——它和nilmap 行为一致，必须先判m != nil
chan struct{} 用于信号通知的正确姿势
当通道只用来“发个信号”，不传数据时，chan struct{} 是唯一合理选择。用 chan bool 或 chan int 都是浪费内存且语义不清。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
chan struct{}做带缓冲的限流器，但忘记在 goroutine 退出前从 channel 取走 token，导致死锁 - 向已关闭的
chan struct{}发送值，触发 panic：send on closed channel - 接收方用
<-ch阻塞等待，但发送方用close(ch)后未做任何 cleanup，goroutine 泄漏
推荐写法：
done := make(chan struct{})
go func() {
defer close(done) // 确保一定关闭
// ... 工作逻辑
}()
<-done // 等待完成
空结构体作为方法接收器时的内存陷阱
定义 type Service struct{} 并为其添加方法，看似零开销，但若该类型被嵌入到其他 struct 末尾，可能因内存对齐被强制填充字节——这不是 bug，而是 Go 编译器为指针安全做的保护。
关键点：
- 单独使用
Service{}实例，内存占用确实是 0 - 但
type Wrapper struct { Data string; svc Service }中，svc在末尾时，整个Wrapper大小可能变成 24 字节（x64），而非预期的 16 字节 - 规避方式：把
Service放在字段开头，或用指针接收：func (s *Service) Do()（此时接收器本身不参与结构体内存布局）
两个 struct{} 变量地址相同，但不能直接比较
Go 1.17+ 起，&a == &b 对两个 struct{} 变量会编译报错：invalid operation: a == b (struct containing no fields)。这是语言规范收紧，不是 bug。
所以不要写这类判断：
- ❌
if &a == &b { ... } - ✅ 正确做法是：值比较永远为
true（a == b合法且恒真），或用unsafe.Pointer(&a) == unsafe.Pointer(&b)（仅调试场景，生产慎用） - ⚠️ 注意：逃逸分析可能让局部变量的地址不同——比如函数内多次调用返回
struct{}，它们的地址未必相同
真正需要关注的，从来不是“地址是否一样”，而是“有没有隐式分配、有没有意外逃逸、有没有对齐膨胀”。这些细节，在压测高并发服务时才会突然跳出来咬人。
