fongfiafia的博客

Go工程和依赖管理基本机制依赖管理机制的变迁GoPath—>GoVendor---->GoModGoPath：会要求工程代码要保存在GoPath/src的目录下面。同时要求你的依赖库也要是这个目录下面的：$GOPATH/src/yourProject/$GOPATH/src/gorm :如果依赖了gorm编译的时候会直接使用GoPath/src目录下的代码。Go Get下载的代码也会放在GoPath中。往往我们在安装Go以后，通过go env查看我们的Go Path，

Go没有提供断言。不可否认，断言十分方便。但是按我们的经验来看，程序员往往会因为不想思考如何更好的处理异常，而滥用断言。更好的异常处理意味着，当服务遇到非致命的错误，仍然会继续运行。精确的错误类型会让程序员定位错误更加快速。我们知道这是一个争议点，Go语言和其他现代语言有许许多多不同点，也是因为我们认为这些设计是值得做的尝试。...

Go为什么没有泛型详细可以见issue：https://github.com/golang/go/issues/43651 ，这个issue已经被认同，不出意外的话在Go的1.18版本就能支持泛型了。Go希望被设计为一个能够被容易持续运行很久的服务端语言（详细可参考这篇文章https://talks.golang.org/2012/splash.article），因此设计的时候聚焦于可拓展性、可阅读性和并发性上，因此当时看来多态编程并不是必不可少的，所以就忽略了。现在语言原来越成熟完善，可以开始考虑泛

Go为什么没有一些某某特性？每一种语言要么会有一些新颖的设计，当然也可能会忽略一些人们喜欢的设计。Go语言设计时希望做到更好的编程体验，更快的编译速度，正交性的概念（ orthogonality of concepts），以及能够做到基本的并发、垃圾回收。基于以上设计考虑，你所喜欢的特性可能在Go语言中就不那么合适，因为它们或多或少降低了编译速度、降低了设计的整洁，也可能会让基础系统架构变得很复杂。如果因为Go少了某些你想要的特性，请原谅我们，也希望您更加关注Go独特的一些特性。探索这些特性也许会让你感

Go的字符标识设计我们避免过于围绕ASCII来设计Go，我们希望增大标识符的容量大小，至少比7位（bit）的ASCII容量要大。组合字符（Combining characters）（PS：Unicode标准认为“基字符”组合成的字符叫做组合字符）不在设计之中，例如梵文。一个Go的规定：标识符只能是字母或者数字，这是一个易懂的同时也充满限制的规则。上述规则有一个缺点。根据定义，一个标识符要被外部引用，首字母必须是大写，而一些由字符组成的标识符无法满足这个规则（首字母大写），因此永远无法被外部引用。目前

GO有“运行时”设计吗？Go是有“运行时”库(runtime)的，它是每一个Go程序不可缺少的一部分。“运行时”库实现了垃圾回收、并发、栈管理以及其他Go重要的特性。Go的“运行时”库类似于C语言的libc库。但是要知道一点，Go的“运行时”库并不是指虚拟机的设计，这点和Java的“运行时”设计不同（PS：Java的“运行时”，是指JVM）。因为Go程序会提前编译为原生机器代码（可能会是Javascript、WebAssembly…），所以，尽管“运行时”通常描述为某种程序运行的虚拟环境，但是在Go中，

注释以后就使用行注释，而不用块注释API网站https://studygolang.com/pkgdoc变量golang变量如果没有赋初值，默认会给零值数据类型：函数，管道，接口（这几个还是比较特殊的）整数类型：默认是int类型，可以通过fmt.printf(“%t”,a) 打印出来具体的类型。字符串：字符串一旦赋值了，就不能再改变了city := “beijing”city[0] = ‘a’ // 这样是不行的数据类型转化例如var int64 a = int