新手最近在学习 Go，学习的时候有个小问题这几天我一直觉得很困扰。。求助一下大佬们

[gitlight]

Q:当编写实体的 CRUD 接口的时候，到底是向上层传指针呢，还是传实体？ 举个例子：

// 实体
type person struct {
	ID   uint
	name string
	age  uint
}

// 指针传递
func getPerson(ID uint) (*person, error) {
	return nil,errors.New("err")
}

// 值传递
func getPerson_second(ID uint) (person, error) {
	return person{}, errors.New("err")
}

纠结这个问题其实是因为在写接口的过程中发现，Go 里是没办法让一个实体类直接返回 nil ，只能返回默认构造参数的结构体，不然 ide 会报错，而使用结构体的指针可以返回 nil 。我虽然明白可以通过 err 返回值来处理错误，但是总觉得生成一个和非空的类外表一样的类返回给上层，会有潜在的危险，并且当类比较复杂的时候，可能会产生额外的开销。

接下来这个延申问题同样很困扰我：像 Go 这样存在指针而且语法很像 C/C++系但同时又存在 GC 的语言，大量使用指针传递对 GC 来说是好还是坏？要是在 IO 密集的 Web 应用场景下，这样大量地使用指针在堆上分配空间会不会加重 GC 的负担，反而会比值传递这种栈复制来得更慢，而不是让程序变得更快？

[hxysnail]

我的项目都是统传递指针，保持简单；另一方面，指针也更加灵活。至于 GC 性能问题，等出现再说，肯定有解决手段，总不能因为性能退回去写汇编吧。项目迭代有一条原则，就是不要过早做性能优化，心里有数就行。

[Trepverter]

OP 能否分享一下 StackOverflow 的英文帖子链接

[ZSeptember]

写业务，传值，CPU 都不是业务代码的性能瓶颈。
写业务，最好是减少副作用，防止在上面地方修改了值都不知道，很难排查。