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

tl; dr ：

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

一种应该经常使用指针的情况：

• 接收器 比其他参数更经常地使用指针。方法修改被调用的东西或命名类型为大型结构并不罕见，因此，在极少数情况下，指南是默认使用指针。

  • 杰夫·霍奇斯（Jeff Hodges）的copyfighter工具自动搜索按值传递的非微小接收者。

在一些不需要指针的情况下：

• 代码审查指南建议将 小结构（ 如

  type Point struct { latitude, longitude float64 }

  ，甚至可能更大的东西）作为值传递，除非您调用的函数需要能够就地对其进行修改。
  • 值语义避免混叠情况，在此情况下，此处的赋值会意外更改其值。
  • 牺牲一些干净的语义来加快速度并不是一件容易的事，有时通过值传递小结构实际上会更有效，因为它避免了高速缓存未命中或堆分配。
  • 因此，Go Wiki的代码审查注释页建议在结构较小且可能会保持这种状态时按值传递。
  • 如果“大”临界值似乎含糊，那就是；可以说，许多结构都在指针或值确定的范围内。作为下限，代码审查注释建议切片（三个机器字）可以合理地用作值接收者。接近上限时，

    bytes.Replace

    需要使用10个单词的args（三个切片和一个

    int

    ）。

• 对于 slices ，您不需要传递指针来更改数组的元素。例如，

  io.Reader.Read(p []byte)

  更改的字节

  p

  。可以说这是“对待像值一样的小结构”的特例，因为在内部，您正在传递一个称为 切片头 的小结构（请参阅Russ Cox（rsc）的说明）。同样，您也不需要指针来 修改地图或在channel上进行通信 。

• 对于 切片，您将 进行 切片 （更改其开始/长度/容量），内置函数，例如

  append

  接受切片值并返回一个新值。我会模仿的；它避免了混淆，返回一个新的分片有助于引起人们注意可能分配了一个新数组的事实，并且调用者很熟悉它。
  • 遵循这种模式并不总是可行的。一些工具，例如数据库接口或序列化器，需要追加到在编译时类型未知的片上。他们有时会接受指向

    interface{}

    参数中切片的指针。

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

  • 您可能仍然需要通过指针在罕见的情况下，要 修改 调用者的结构：

    flag.StringVar

    需要一个

    *string

    出于这个原因，例如。

使用指针的位置：

• 考虑您的函数是否应该是您需要指向的任何结构上的方法。人们期望有很多方法可以

  x

  进行修改

  x

  ，因此使接收器成为修改后的结构可能有助于最大程度地减少意外。对于何时应该将接收者作为指针有一些指导。

• 对非接收器参数有影响的函数应该在godoc中，或者更好的是，在godoc和名称（如

  reader.WriteTo(writer)

  ）中明确指出。

• 您提到接受一个指针，以允许通过重用避免分配。为了内存重用而更改API是一种优化，我会延迟直到明显知道分配费用不菲，然后再寻找一种不会对所有用户强制使用棘手API的方法：

  1. 为了避免分配，Go的转义分析是您的朋友。您有时可以通过创建可以用平凡的构造函数，纯文本或有用的零值初始化的类型来帮助避免堆分配

     bytes.Buffer

     。
  2. 考虑一些

     Reset()

     将对象放回空白状态的方法，例如某些stdlib类型提供的方法。不在乎或无法保存分配的用户不必调用它。
  3. 为方便起见，

     existingUser.LoadFromJSON(json []byte) error

     可以考虑编写就地修改方法和从头创建函数作为匹配对，以方便使用：可以用进行包装

     NewUserFromJSON(json []byte) (*User, error)

     。再次，它在懒惰和捏分配给单个呼叫者之间做出选择。
  4. 寻求回收内存的调用者可以让他们

     sync.Pool

     处理一些细节。如果特定的分配产生了很大的内存压力，您有信心知道何时不再使用该分配，并且没有更好的优化方法可以提供

     sync.Pool

     帮助。（CloudFlare发表了

     sync.Pool

     关于回收的有用（上）博客文章。）

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

• 用于创建商品的API 可能会强制您使用指针，例如，您必须调用

  NewFoo() *Foo

  而不是让Go初始化为零值。
• 这些项目的期望寿命 可能不尽相同。整个切片立即被释放；如果99％的项目不再有用，但您有指向其他1％的指针，则所有数组均保持分配状态。
• 到处移动项目 可能会引起问题。值得注意的是，

  append

  在增长基础数组时会复制项目。指向

  append

  错误位置之后的指针，对于大型结构，复制可能会变慢，并且例如，

  sync.Mutex

  不允许复制。在中间插入/删除并类似地移动项目。

从广义上讲，如果您将所有物品放在前面就位并且不移动它们（例如，

append