我一直在考虑在内部设置一个godoc服务器，但我和我的团队一致认为，当你有一个大型的$GOPATH时，浏览godoc并不容易。我们遇到的问题在于如何列出子目录和子包，即如何在目录内显示目录，以及如何在包内显示包。结果是，你最终不得不使用你的浏览器的“查找”功能来在极其冗长且难以跟踪的页面上找到你正在寻找的内容。
这个问题的另一个问题是，它使得加载包主页的速度变慢很多，因为页面可能会变得相当长 - 即使在相当强大的硬件上也是如此。
我在godoc代码中快速查看了一下，发现了一个似乎合理的地方来放置一个新的选项，用于显示包和子目录的显示方式，并在over here中创建了一个分支。我也会为此提交一个PR,但从贡献指南来看，我似乎还应该提交一个可以链接到的问题。
所有这些都只是允许你在URL中添加?m=shallow,并且它只会显示你正在查看的顶级包和目录。
我脑海中的另一个变化是，当godoc启动时，指定默认的PageInfoMode值会很好，这样你就不必总是将其添加到URL中，但我还没有机会去研究这个问题。
4条答案
按热度按时间s6fujrry1#
https://golang.org/cl/135338提到了这个问题：
godoc: add 'shallow' PageInfoMode to only show top-level directories in subdirectory listingsmlnl4t2r2#
谢谢。我认为正确的方法是将子目录折叠到一定深度(假设为2)的可折叠区域，用加号(*)表示可以展开。
自Go 1.11版本以来，我对此进行了一些小的改进，即将包列表分为标准库和第三方库，并将它们放在可折叠区域下。因此，至少当你浏览标准库时，你可以折叠第三方部分，反之亦然。
我想做这个折叠功能，但请注意，在1.11版本中，GOPATH已经不存在了。/pkg/列表显示的概念不再存在。一切都是针对特定模块的。所以一旦输出变得模块化，它将自动仅显示该模块的包，从而大大减少输出。
我请求你等待#26827修复后再进行操作。在那之后，如果我们发现列表仍然难以管理，我们可以探讨解决方法。但现在，添加一个可能在未来并不真正需要的额外标志似乎有些多余。
m2xkgtsf3#
我认为正确的方法是将子目录折叠到一定深度(假设为2)以内，并用一个可展开的加号(*)表示。这肯定会有很大的改进。需要记住的一件事是，不同的包会在不同的深度“开始”。我们现在在内部使用BitBucket,所以我们的包结构如下：
因此，我认为我们会看到这样的结果，但还有其他用户，例如gopkg.in用户，或者使用虚荣URL的其他用户，他们可能更像这个虚构的包：
因此，即使折叠到2层级，这些页面仍然可能很难浏览。我知道这只是个建议，但我觉得值得讨论为什么这不是一个简单的问题来解决。如果不折叠，只显示最大深度为0,它确实可以解决这些问题。
也许它们可以折叠到第一个包含Go文件的目录或模块。因此，上面第二个示例将在
tools停止，而第一个示例将在<repo name>停止？一切都是特定于模块的。所以一旦输出变得模块化，它将自动仅显示该模块的包，从而大大减少输出。
这是个好观点，那里会变得更短。在这个情况下，团队如何在国内设置godoc服务器？实际上我只想找一个东西来集中管理我们的包文档，以便更容易地发现我们拥有的包，然后浏览它们的文档。
wgxvkvu94#
在这个场景下，团队应该如何着手在内部设置godoc服务器？
我们还在努力解决这个问题。正如@ianthehat在这里指出的-#24661(评论)。
我更倾向于等到godoc模块的问题得到解决后再考虑这个问题。如果我们最终还是有很长的页面，那么再重新审视这个问题。在此之前，说正确的方法还为时过早，我们可能会做一些后来可能变得无关紧要的事情。