Go不支持对结构体指针直接解构，必须先解引用再字段访问或赋值；空结构体指针无字段可解构，常用于信号传递。
解构结构体指针时直接用 *p 还是 p？
Go 不支持对指针变量做结构体解构（即所谓“解引用后解构”），var {a, b} = *p 是非法语法。你只能先解引用，再对值做结构体字面量赋值，或者用字段访问方式逐个取值。
常见错误现象：invalid operation: cannot assign to struct literal 或 syntax error: unexpected {，往往出现在写成 {x, y} := *p 时。
- 正确做法是显式解引用 + 字段访问：
x, y := p.X, p.Y - 如果想批量赋值，必须先转成值类型：
val := *p; x, y := val.X, val.Y - 注意：若结构体较大，
*p会触发一次内存拷贝，不是零成本操作
struct{} 指针解构有没有特殊行为？
空结构体 struct{} 占用 0 字节，但它的指针仍占用指针大小（通常 8 字节），解构它本身没有意义——因为没字段可取。但常有人误以为能靠解构来“忽略”某个返回值中的空结构体指针。
使用场景：常见于接口实现或 channel 信号传递，比如 done chan *struct{}。
立即学习“go语言免费学习笔记（深入）”；
if s := 是合法的，但 <code>_, _ := *s会编译失败- 不能对
*struct{}做字段解构，连(*s).X都不存在——它根本没字段 - 别试图用
struct{}指针模拟“可选空值”，它不提供任何额外语义，只是占位符
嵌套结构体指针解构容易漏掉哪一层？
当结构体字段本身是指针（如 type User struct { Profile *Profile }），解构时很容易忘记中间的 * 层级，导致空指针 panic 或字段为零值。
典型错误现象：panic: runtime error: invalid memory address or nil pointer dereference，发生在访问 u.Profile.Name 但 u.Profile == nil 时。
- 安全写法是分步检查：
if u.Profile != nil { name := u.Profile.Name } - 不要写
name := (*u.Profile).Name——这和u.Profile.Name等价，但徒增误解 - Go 的自动解引用只作用于单层字段访问，不会递归穿透多层指针链
为什么不能用 reflect 自动解构结构体指针？
可以，但代价高、不安全、且无法保证字段顺序或类型匹配。反射解构常被当成“通用解构方案”，实际在绝大多数业务代码里属于过度设计。
性能影响明显：反射调用比直接字段访问慢 10–100 倍，且无法内联、逃逸分析更复杂。
- 若真需动态解构，优先考虑
encoding/json或map[string]interface{}转换路径 -
reflect.ValueOf(p).Elem().FieldByName("X").Interface()可能 panic，必须手动检查IsValid()和CanInterface() - 字段名大小写敏感，导出性（首字母大写）决定是否可被反射读取——这点极易被忽略
