运行一段程序，警告：
service/mysqlconfig.go:63::error: golang.guazi-corp.com/tools/ksql-runner/model.CreatingMysqlMongodbRecord composite literal uses unkeyed fields (vet)
其中，composite literal uses unkeyed fields这个警告找了很久原因，最终发现是结构体初始化的问题，自己埋雷。
例如，结构体定义如下，
|
1
2
3
|
type A struct {
*B
}
|
使用下边无键字段初始化，就会警告：
varA := A{b} // b is of type *B
在自己看来b的类型是B*，但编译器却不认账。
正确初始化方法是：
a := A{B: b}
有人说是，这只是针对"go vet"中的一个错误的解决方法。
因为go vet默认情况下执行所有检查，如果任何标志显式设置为true，则仅运行那些测试。
相反，如果任何标志显式设置为false，则仅禁用那些测试。
因此-printf = true运行printf检查，-printf = false运行除printf检查之外的所有检查。
可以禁用这个检查，也可以修改代码，但是规范代码更比较合适。
虽然这只是一个警告，有人觉得无关紧要，但是当你几周或者几个月后在结构体中添加了一个字段，那么你使用unkeyed初始化的所有东西都会被破坏。显然，在一个项目中不希望遇到这种错误。
补充：golang中结构体的初始化方法(new方法)
准备工作：
定义结构体：Student
|
1
2
3
4
5
6
7
8
9
10
|
import (
"fmt"
"reflect"
)
type Student struct {
StudentId string `json:"sid"`
StudentName string `json:"sname"`
StudentClass string `json:"class"`
StudentTeacher string `json:"class"`
}
|
测试代码如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
func main() {
s0 := Student{}
fmt.Println(s0)
fmt.Println(reflect.TypeOf(s0))
s1 := new(Student)
fmt.Println(s1)
fmt.Println(reflect.TypeOf(s1))
s2 := &Student{}
fmt.Println(s2)
fmt.Println(reflect.TypeOf(s2))
s3 := &Student{"", "", "100", "200"}
fmt.Println(s3)
fmt.Println(reflect.TypeOf(s3))
s4:= &Student{StudentId: "100", StudentName: "200"}
fmt.Println(s4)
fmt.Println(reflect.TypeOf(s4))
}
|
输出结果：
|
1
2
3
4
5
6
7
8
9
10
|
{ }
main.Student
&{ }
*main.Student
&{ }
*main.Student
&{ 100 200}
*main.Student
&{100 200 }
*main.Student
|
注意：
除了s0以外，s1-s4变量全部为指向Rect结构的指针(指针变量)，因为使用了new()函数和&操作符
而s0的方法 s0 := Student{} 表示的是一个Student类型，两者是不一样的
在Go语言中，未进行初始化的变量都会被初始化为该类型的零值，例如bool类型的零值为false, int类型的零值为0, string类型的零值为空字符串． 在Go语言中没有构造函数的概念,对象的创建通常交由一个全局的创建函数来完成,以NewXXX来命令,表示"构造函数":
|
1
2
3
|
func NewStudent() {
return &Student() //返回指针
}
|
用 new 分配内存 内建函数 new 本质上说跟其他语言中的同名函数功能一样：new(T) 分配了零值填充的 T 类型的内存空间，并且返回其地址，一个 *T 类型的值。
务必记得 make 仅适用于 map，slice 和 channel，并且返回的不是指针。应当用 new获得特定的指针。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方，望不吝赐教。
原文链接：https://blog.csdn.net/hhhanpan/article/details/81943378