在某些情况下，您确实希望显示这些信息。如果隐藏它们，那么就无法有意地显示这些信息。在某些情况下，您不希望显示这些信息，在这种情况下，解决方法非常简单：#11758(评论)。
无论是策略结果对于一个用例来说还是另一个用例来说都不理想。然而，当前的策略更加灵活，所以似乎更好的选择。

确实，这是直接的，但Russ提出的解决方案仍然会显示一些我认为对于阅读文档的人来说没有用的东西，并且可能会显示一些内部细节。
包https://godoc.org/golang.org/x/text/encoding/charmap中的变量文档就是一个例子。
Godoc显示：

var CodePage037 *Charmap = &codePage037

这只是添加噪声。
那么如何使用自定义约定让godoc隐藏初始化呢？
作为一个例子，使用_前缀：

var X = _x

谢谢。

我们已经有很多约定，比如BUG和DEPRECATED。我个人希望godoc保持最小化和干净。一般来说，向变量或方法接收者添加_并不被认为是Go的惯用方式。以某种方式编写注解是可以的，但godoc不应该规定如何编写代码。
/cc @dmitshur@andybons 用于决策。

保持godoc简单是一个很好的理由。但是我仍然不喜欢这样一个事实，即需要修改代码以使工具正确执行操作，就像https://github.com/googleapis/google-cloud-go/blob/master/firestore/options.go#L34中的情况一样。但这可能是一个非常罕见的情况。
谢谢。

制作一个工具做正确的事情
对于像半自动生成的文档这样的东西，它被人类消费时，并不总是清楚“正确的事情”是什么。正如前面提到的，有些情况下你确实希望显示未导出的初始化器，而有些情况下则不希望。在你建议的约定中，那些确实希望显示未导出初始化器的用户如何实现这一点？
var X = _x
我不确定这是否是更好的文档记录方式。它完全没有告诉我X的类型。
Russ提出的解决方案仍然会显示一些内容。Russ的解决方案只是众多方案之一。如果你绝对不想显示任何内容，你可以这样做：

var ExportedGlobal MyType

func init() {
    ExportedGlobal = ... // hidden variable initialization logic
}

请注意，#11758中的案例有些不同：在这个例子中，初始化器本身不包含任何显式的非导出标识符(甚至函数调用),因此不太明显初始化器对外部用户没有用处。

如果你隐藏它，那么就无法故意显示这些信息。

在公共文档中，有哪些例子是故意想要显示显式未导出的标识符的？

另外请注意，我们已经有一个现有的机制来明确显示API的未导出部分：?m=all查询参数和-u标志。

在公共文档中，有哪些情况下你希望展示显式的未导出标识符？
以下是一些真实的例子(出于明显的原因，名称被混淆):

var MaxSize = 1024 * 1024 * envUint64("MAX_LOG_MB")

var MaxTimeout = Duration(100*milliseconds)

var GlobalCache = &Cache{maxSize: 64*1024*1024}

好的，这个看起来很整洁。但是用户应该如何知道 envUint64 的作用呢？(这个数字是整数、浮点值还是其他什么？如果设置了但无效，程序会崩溃吗，还是忽略它？有特殊的区分值吗？)

因此，使用显式的注解或者只使用导出的函数可能会更清晰：

或者

(用户可以点击链接查看某个辅助包中 env.Uint64 的文档。)

为什么用户会更倾向于这种方式而不是使用具有正确文档的导出标准库类型呢？

如果 maxSize 是用户可配置的，为什么不使用标准的配置钩子呢？

或者

如果它不是用户可配置的，为什么用户关心它的配置？无论如何，他们都无法改变它。