空结构体struct{}确实不占内存（unsafe.sizeof(struct{}{})==0），但仅在map value、channel元素、切片底层数组等按元素分配的场景真正省空间；嵌入结构体字段可能干扰对齐，指针或反射中易引入隐性成本。
空结构体 struct{} 确实不占内存（unsafe.Sizeof(struct{}{}) == 0），但它不是“哪里都能塞进去就省空间”的万能膏药。真正省下的，是 map value、channel 元素、切片底层数组这些**按元素计数分配**的场景；而它在结构体字段、接口值、指针间接引用中，反而可能引入对齐干扰或语义模糊。
map[string]struct{} 比 map[string]bool 真的更省内存？
是的，但只省在 value 存储层，且仅当 key 数量极大时才明显。
- 每个
map[string]bool的 bucket 中，value 占 1 字节（bool大小）＋ 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 发送操作必须带右值，<code>struct{} 没有字面量简写形式。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法只有：
ch - 接收端可忽略值：
，或显式接收：<code>_ := - 缓冲通道
make(chan struct{}, N)中，N 可设为 1e6 甚至更大，底层不为每个元素分配内存；而make(chan bool, N)会真实分配 N 字节，可能引发 page fault - 关闭通道
close(ch)是更明确的“终止”语义，比发送再接收更推荐用于退出通知
嵌入 struct{} 到自定义结构体里，会增大体积吗？
不会增加结构体总大小，但会影响字段偏移和对齐边界，尤其当它不在末尾时。
-
unsafe.Sizeof对含struct{}的结构体仍返回正确总字节数，该类型自身贡献为 0 - 若
struct{}出现在中间位置（如type T struct { x int64; _ struct{}; y int32 }），它不改变最大对齐要求（仍是 8），但会让编译器把y的起始偏移卡在x结束处（即 offset=8），而不是像普通byte那样触发 4 字节对齐调整 - 不能对结构体内的
struct{}字段取地址：&s._编译报错cannot take address of s._，因为它无独立存储位置 - 别把它当“注释字段”滥用——语义不清，还可能干扰反射或序列化逻辑（比如某些 JSON 库直接跳过
struct{}字段）
哪些地方看似能用 struct{}，实际是坑？
最常踩的三个隐性成本点：slice 元素、指针间接、反射上下文。
-
[]struct{}的底层数组长度为 0 字节，但切片头（len/cap/data）仍占 24 字节（64 位系统），别误以为整个 slice 是“零开销” -
*struct{}是合法类型，但指针值本身占 8 字节，且指向的地址不可靠（可能为zerobase或 nil），无法安全解引用 - ORM 或 YAML/JSON 序列化时，
struct{}字段常被跳过或序列化为空对象{}，导致数据丢失或反序列化失败；若需保留字段占位，应改用map[string]interface{}或明确空结构体标签 - 函数返回值若声明为
func() struct{}，调用方必须接收该值（哪怕丢弃），不能省略——这和func()的 void 语义不同，容易写错
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
