用&Struct{}取地址需加括号，因&优先级低于字面量；匿名结构体类型严格匹配，跨包或命名类型不兼容；嵌套指针易空panic，需显式判空；性能无优势且调试困难，仅适用于临时场景。
用 &struct{} 直接取地址是合法的，但得加括号
go 允许对字面量取地址，匿名结构体也不例外。但常见错误是写成 &struct{X int}{1} —— 这会报错 cannot take the address of struct{X int}{1}。因为 & 的优先级低于字面量构造，编译器把它解析成 (&struct{X int}){1}，显然不合法。
正确做法是用括号明确分组：
-
p := &struct{X int}{X: 42}✅ -
p := &(struct{X int}{X: 42})✅（更显式，推荐初学者用） -
p := &struct{X int}{42}✅（位置参数也行，但可读性差） -
p := &struct{X int}{1}❌ 编译失败（缺少括号）
匿名结构体指针不能直接赋值给已声明变量，类型必须严格匹配
Go 的类型系统对匿名结构体很严格：哪怕两个匿名结构体字段完全一样，只要定义位置不同，就是不同类型。这意味着你不能把一个包里定义的 &struct{ID int} 赋给另一个包里写的同结构指针变量。
常见场景是函数返回或 map value 存储：
立即学习“go语言免费学习笔记（深入）”；
- 函数返回
*struct{ID int}，调用方必须用相同字面量声明接收变量，不能提前用type T struct{ID int}替代（否则类型不兼容） - 存进
map[String]*struct{ID int}没问题；但想 later 用map[string]*MyStruct读，就会类型错误 - json 解析时常用
json.Unmarshal([]byte, &struct{...})，此时括号和字段名顺序都影响兼容性
嵌套匿名结构体指针要小心字段对齐和零值传播
当匿名结构体含指针字段（比如 *string 或 *struct{}），初始化时若漏掉该字段，它会是 nil。这本身没问题，但容易在解引用时 panic。
例如：
p := &struct{ Name *string Meta *struct{Version string} }{Name: new(string)}这里 Meta 是 nil，后续如果写 p.Meta.Version = "v1" 就 panic。检查方式只能是显式判空：
- 字段为
nil时不会自动分配内存，也不会触发零值填充 - 嵌套越深，漏初始化风险越高；建议只在临时、一次性场景用，长期结构优先定义命名类型
- 用
go vet无法捕获这类逻辑空指针，得靠测试或静态分析工具如staticcheck
性能上没优势，反而可能增加 GC 压力和逃逸分析复杂度
有人以为匿名结构体能“避免类型定义开销”，其实 Go 编译器对命名和匿名结构体生成的底层代码几乎一致。但副作用明显：
- 每次写
&struct{...}都可能触发堆分配（尤其含 slice/map/Interface 字段时），而命名类型可复用栈空间 - 逃逸分析更难判断生命周期，
go build -gcflags="-m"常看到“moved to heap”提示 - 调试时打印
*struct{...}类型名很长，且不同位置的同结构显示为不同类型，日志难关联
真正适合的场景其实很窄：http handler 里构造一次性的 JSON 响应结构、测试 mock 数据、或者泛型约束中临时描述形状。其他时候，多打几行 type 定义，省下的调试时间远超键入成本。