指针与参数和返回值中的值

type MyStruct struct {
    Val int
}

func myfunc() MyStruct {
    return MyStruct{Val: 1}
}

func myfunc() *MyStruct {
    return &MyStruct{}
}

func myfunc(s *MyStruct) {
    s.Val = 1
}

func myfunc() []MyStruct {
    return []MyStruct{ MyStruct{Val: 1} }
}

func myfunc() []*MyStruct {
    return []MyStruct{ &MyStruct{Val: 1} }
}

func myfunc(s *[]MyStruct) {
    *s = []MyStruct{ MyStruct{Val: 1} }
}

func myfunc(s *[]*MyStruct) {
    *s = []MyStruct{ &MyStruct{Val: 1} }
}

#1 楼

tl; dr：

使用接收器指针的方法很常见；接收者的经验法则是：“如有疑问，请使用指针。”
切片，映射，通道，字符串，函数值和接口值是在内部使用指针来实现的，指向它们的指针通常是多余的。
在其他地方，将指针用于大型结构或您必须更改的结构，否则传递值，因为通过指针使事情意外更改会造成混淆。


在一种情况下，您应该经常使用指针：


接收器比其他自变量更经常使用指针。方法修改被调用的东西或命名类型为大型结构的情况并不少见，因此指导原则是默认使用指针，除非极少数情况。
Jeff Hodges的copyfighter工具会自动搜索非-按值传递的微型接收器。




在某些情况下不需要指针：


代码审查指南建议将较小的结构（例如type Point struct { latitude, longitude float64 }）作为值传递，甚至可能将更大的值作为值传递，除非您调用的函数需要能够在适当的位置修改它们。

值语义避免出现别名情况在这里的赋值会意外地更改那里的值。
牺牲一点干净的语义来加快速度并不是一件容易的事，有时通过值传递小的结构实际上会更有效，因为它避免了缓存丢失或堆
因此，Go Wiki的代码审查注释页建议在结构较小且可能保持这种状态时按值传递。
如果“大”分界线似乎含糊，那就是；可以说，许多结构都在指针或值确定的范围内。作为下限，代码审查注释建议切片（三个机器字）可以合理地用作值接收者。接近上限时，bytes.Replace占用了10个字的args（三个切片和一个int）。您会发现即使复制大型结构也能赢得性能，但是经验法则并非如此。





对于切片，您不希望这样做。需要传递一个指针来更改数组的元素。例如，io.Reader.Read(p []byte)更改p的字节。可以说，这是“对待像值一样的小结构”的特例，因为在内部，您正在传递一个称为切片头的小结构（请参阅Russ Cox（rsc）的说明）。同样，您也不需要指针来修改地图或在通道上进行通信。


对于切片，您将进行切片（更改其开始/长度/容量），在像append这样的函数中，它接受一个分片值并返回一个新值。我会模仿的；它避免了混淆，返回一个新的slice有助于引起人们注意可能分配了一个新数组的事实，并且调用者很熟悉。

遵循这种模式并不总是可行的。一些工具，例如数据库接口或序列化器，需要追加到在编译时类型未知的片上。它们有时会在interface{}参数中接受指向切片的指针。




映射，通道，字符串以及函数和接口值（例如切片）是内部引用或结构，已经包含引用，因此，如果您只是试图避免复制基础数据，则无需将指针传递给它们。 （rsc撰写了有关如何存储接口值的单独文章）。

在极少数情况下，您可能仍需要传递指针以修改调用者的结构：flag.StringVar需要*string，例如。



使用指针的位置：


考虑是否应该将函数用作需要指针的结构上的方法。人们期望x上有很多方法可以修改x，因此使接收器具有修改后的结构可能有助于最大程度地减少意外。关于何时应该将接收者作为指针的准则。



对非接收者参数有影响的函数应该在godoc中或更清楚地指出godoc和名称（就像reader.WriteTo(writer)）。


您提到接受一个指针，通过允许重用来避免分配；为了内存重用而更改API是一种优化，我会等到明确分配成本后再进行优化，然后再寻找一种不会对所有用户施加棘手API的方法：

为避免分配，Go的转义分析是您的朋友。您有时可以通过创建可以用平凡的构造函数，普通文字或有用的零值（例如bytes.Buffer）初始化的类型来帮助避免堆分配。
考虑使用Reset()方法将对象放回空白状态，像某些stdlib类型提供的那样。不在乎或无法保存分配的用户不必调用它。
为方便起见，考虑编写就地修改方法和从头创建函数作为匹配对，以方便使用：existingUser.LoadFromJSON(json []byte) error由NewUserFromJSON(json []byte) (*User, error)包裹。同样，它可以在懒惰和分配给单个调用者之间进行选择。
寻求回收内存的调用者可以让sync.Pool处理一些细节。如果特定的分配产生了很大的内存压力，您可以确定何时不再使用该分配，并且没有更好的优化方法，sync.Pool可以为您提供帮助。 （CloudFlare发布了有关回收的有用的（sync.Pool之前的）博客文章。）



最后，关于切片是否应为指针：值切片可以很有用，并且可以节省分配和缓存未命中。可能存在阻止程序：


用于创建商品的API可能会强制您使用指针，例如您必须调用NewFoo() *Foo而不是让Go初始化为零值。

项目的期望寿命可能并不完全相同。整个切片立即被释放；如果99％的项目不再有用，但您有指向其他1％的指针，则所有数组仍保持分配状态。

移动值可能会导致性能或正确性问题，使指针更具吸引力。值得注意的是，当append扩展基础数组时，它会复制项目。在append指向错误的位置之前获得的指针，对于大型结构（例如，对于sync.Mutex不允许复制。在中间插入/删除并类似地移动项目。

广泛地讲，如果您将所有项目都放在前面并且不移动它们（例如，不或在初始设置后继续移动它们，但您确定可以的话（不能/小心地使用指向项目的指针，项目足够小，可以有效地进行复制等）。有时您必须考虑或衡量具体情况，但这只是一个粗略的指导。

#2 楼

您想将方法接收器用作指针的三个主要原因：


“首先，也是最重要的是，该方法需要修改接收器吗？如果是，则接收器必须是一个指针。”
“第二个要考虑效率。如果接收器很大，例如一个大的结构，则使用指针接收器会便宜得多。”
“下一个是一致性。如果某些方法类型的必须有指针接收器，其余的也应该有指针接收器，因此无论如何使用该类型，方法集都是一致的”。

参考：https://golang.org/doc/faq#methods_on_values_or_pointers

编辑：另一个重要的事情是知道要发送给函数的实际“类型”。该类型可以是“值类型”或“引用类型”。

即使切片和映射充当引用，我们也可能希望在更改切片长度的情况下将它们作为指针传递在功能中。

#3 楼

通常，在构造某些有状态或可共享资源的实例时，通常需要返回一个指针。这通常是通过以New开头的函数来完成的。

因为它们代表某物的特定实例并且可能需要协调某些活动，所以生成重复/复制的结构没有多大意义。表示相同的资源-因此返回的指针充当资源本身的句柄。

一些示例：




func NewTLSServer(handler http.Handler) *Server-实例化用于测试的Web服务器

func Open(name string) (*File, error)-返回文件访问句柄

在其他情况下，仅由于结构可能太大而无法默认复制而返回指针：



func NewRGBA(r Rectangle) *RGBA －在内存中分配图像


或者，可以通过直接返回指针的副本来避免直接返回指针内部包含指针的结构，但也许这不是惯用语言：


在标准库中找不到此类示例...
相关问题：在Go中嵌入尖角r或具有值

#4 楼

如果可以（例如，不需要传递作为参考的非共享资源），请使用一个值。出于以下原因：


您的代码将更美观，更易读，避免了指针运算符和null检查。
您的代码将更安全地避免Null Pointer恐慌。
您的代码通常会更快：是的，更快！为什么？

原因1：您将在堆栈中分配较少的项目。从堆栈上分配/取消分配是立即进行的，但是在堆上分配/取消分配可能会非常昂贵（分配时间+垃圾回收）。您可以在此处看到一些基本数字：http://www.macias.info/entry/201802102230_go_values_vs_references.md

原因2：特别是如果将返回的值存储在切片中，则存储对象将更加紧凑在内存中：循环遍历所有项都是连续的切片比遍历遍历所有项都是指向内存其他部分的指针的切片要快得多。不是为了间接步骤，而是为了增加缓存未命中率。

神话破灭：典型的x86缓存行为64字节。大多数结构都比那个小。在内存中复制高速缓存行的时间类似于复制指针。

仅当代码的关键部分很慢时，我才会尝试进行一些微优化，并检查使用指针是否会提高速度，但以降低可读性和可维护性为代价。