大佬们，为什么我感觉 go 文档要比前端文档难懂

因为 go 本身基于注释的文档不好用(Rust 的就好很多有高亮有补全)，所以开发者都不太喜欢在注释里写，基本都在 repo README 里。go.dev 我一般都是拿来还没用的时候看一下整体结构啥的

@pkoukk 点名批评 nodejs 文档，从来没见过如此敷衍的东西

@sky3hao #14 2025 年了，到现在还有这种狭隘思想存在的人。。。

@BeautifulSoap 深以为然。文档上的基本没有结构、详尽的用法。即使是标准库上的注释（虽然已经很长了）也得不可避免地一层层点下去看怎么实现的。

封装的好的 api 一般在文档里会有 examples ，并且你看 go test 也可以看个大概的用法。我觉得是 go 本身语法简单，所以知道某个库的用途，大概看方法的参数和逻辑，就可以知道了。

Go 的文档在一定程度上混淆了 Doc 和 Reference ；虽然叫 godoc ，但是更多的还是以 reference 存在的

相比之下 Rust 就好很多 —— 虽然 doc 和 reference 还是融合在一起的，但是专门为 doc 做了非常多的优化

另外，同等比较的话，应该是用 typedoc 来比？而不是用 React 自己的文档站……

之前我就奇怪 demo 不仅数量少，而且有些贴一大段找不到重点。后来看了源码才发现，demo 是从 test 文件里抄的，就是测试代码。太会偷懒了。

确实难懂，很多 go 项目其实跟#26 说的一样，doc 跟 reference 是混淆的。

不习惯的话确实非常难受，没办法，go 的许多项目就这样。

习惯了的话其实也还凑合，进一个项目先翻 example 和 tests 就能找到大概用法了。

@sky3hao 不是吧，哥们

关键问题是：examples 太少了。如果像 PHP 文档那样，就不会有这个主题了。

C++库的文档更烂，要么又臭又长，要么非常短，想用明白?自己看源码去吧

老传统了。RTFM 。。。

确实不好，Go 生态很多文档的很多方法都是一句话带过，文档额外提供的信息跟函数名差不多，稍微深入一点就要搜索、问 ai 、源码+playground"白盒测试"

go 还要看文档吗？不都是看源码吗

是的，Go 文档颇有上世纪风格，在 21 世纪还这么设计，除了故意折磨用户之外我想不出其他理由了。

随便举几个例子：
1. 一眼望去基本就三种颜色，黑色的背景、白色的文字、蓝色的链接，毫无区分度
2. 代码连语法高亮都不给
3. ToC 这种东西放在开头毫无意义，单纯挤占正常阅读空间
4. 边上可以全部展开的导航栏又不展开，到这里又开始省空间了？
5. 搜索界面跟 GPT2 设计的一样，仿佛没学过布局，而且鼠标移上去下划线是竟然是出现在类型上？？
6. 不能跨模块搜索

我觉得这玩意儿能气死 UX 设计师

因为你看的：

一个是 doc ！

另外一个是代码注释！

一个是写文档的时候特别写的，一个是写代码是顺便写的。


你应该问：

问什么多 go 项目没有专门文档(doc)，那么回答可能是因为 easy ，看数据结构就行。

而且你看的不是一个级别东西。

react 是一个主要面向开发者的库，专注的是开发体验。
request 也是一个开发库，专注开发体验。

这两个东西需要文档。。。


git 包大部分代码专注于数据结构和流程，体验在命令行接口那块。

正常，就是前后端熟练程度不一样。我是后端，看前端的文档觉得更费劲，后端不管文档写得怎么样，可以直接翻看源码，单步调试来理解，前端因为对运行机制不熟悉，调试，源码这个依赖路径不太灵了就

因为前端和 Python 的文档是人写的，Go 的是直接代码的接口生成的。
前面的有样例，而且 Go 的和看代码没区别