new与make之间有什么不同？
new 分配内存，make 初始化切片、映射和信道类型
如何获得方法的动态分配？
拥有动态分配方法的唯一途径就是通过接口。结构或其它混合类型的方法总是静态地确定
如何编写单元测试？
在相同的目录中创建一个以 _test.go 结尾的新文件作为你的包源文件。 在该文件中，加入 import "testing" 并编写以下形式的函数：
func TestFoo(t *testing.T) {
...
}
在该目录中运行 go test。该脚本会查找 Test 函数， 构建一个测试二进制文件并运行它。
闭包作为Go程在运行时会发生什么？
当闭包与并发一起使用时，可能会产生一些混乱。考虑以下程序：
func main() {
done := make(chan bool)
value := []string{"a", "b", "c"}
for _, v := range values {
go func() {
fmt.Println(v)
done <- true
}()
}
// 在退出前等待所有Go程完成
for _ = range values {
<-done
}
}
有人可能会错误地希望看到 a, b, c 作为输出。而你可能会看到 c, c, c。这是因为每一次循环迭代中都使用了变量 v 的相同实例，因此每一个闭包都共享了单一的变量。当该闭包运行时，它将在 fmt.Println 执行后打印出 v 的值，但 v 可能已经在Go程启动后被修改了。要在这类问题发生前发现它们，请运行 go vet。
要将 v 的当前值在每一个闭包启动后绑定至它们，就必须在每一次迭代中， 通过修改内部循环来创建新的变量。其中一种方式就是将变量作为实参传至该闭包中：
for _, v := range values {
go func(u string) {
fmt.Println(u)
done <- true
} (v)
}
在这个例子中，v 的值作为一个实参传入了该匿名函数。然后这个值就可作为变量 u 在该函数中访问了。
甚至只需简单地创建新的变量，使用声明的风格看起来可能有点怪，但这在Go中能很好地工作：
for _, v := range values {
v := v //创建新的"v"
go func() {
fmt.Println(v)
done <- true
} ()
}
为什么T与*T拥有不同的方法集？
根据Go规范中的定义
其它任意已命名类型
T的方法集由所有带接收者类型T的方法组成。 与指针类型*T相应的方法集为所有带接收者*T或T的方法的集（就是说，它也包含T的方法集）。
如果一个接口值包含一个指针 *T，一个方法调用可通过解引用该指针来获得一个值， 但如果一个接口值包含一个值 T，就没有可用的方式让一个方法调用获得一个指针。
即便在编译器可以获得传入方法的值的地址的情况下，若该方法修改了该值，则更改会在调用者中丢失。 一个常见的例子是
var buf bytes.Buffer
io.Copy(buf, os.Stdin)
会将标准输入复制到 buf 的副本中，而不是复制到 buf 自身。这几乎是从不期望的行为。
应当为值或指针定义方法吗？
func (s *MyStruct) pointerMethod() {} //为指针定义的方法
func (s MyStruct) valueMethod() {} //为值定义的方法
当为一个类型定义了一个方法，则接收者（上面例子中的 s）的表现正好就是该方法的实参。 将接收者定义为值还是指针都是一样的问题，就像一个函数的实参应该是值还是指针一样。 有几点需要考虑的地方。
首先，也是最重要的一点，方法需要修改接收者吗？如果是，则接收者必须是一个指针。 （切片和映射的行为类似于引用，所以它们的状况有一点微妙，但比如说要改变方法中切片的长度， 则接受者仍然必须是指针。）在上面的例子中，如果 pointerMethod 修改了 s 的字段，那么调用者将观察到那些改变，但 valueMethod 是由调用者实参的副本调用的（这是传值的规定），因此对它的更改对于调用者来说是不可见的。
顺便一提，指针接收者在Java中的情况和Go是相同的，尽管在Java中指针隐藏在幕后； 而Go的值接受者则不相同。
其次是效率问题的考虑。若接受者很大，比如说一个大型的 struct， 使用指针接收器将更廉价。
接着是一致性问题。若某些类型的方法必须拥有指针接收者，则其余的也应该这样， 因此不管该类型被如何使用，方法集都始终如一。更多详情见方法集一节。
对于诸如基本类型、切片以及小型 struct 这样的类型，值接收者是非常廉价的， 因此除非该方法的语义需要一个指针，一个有效而清楚的值接收者。
函数形参在什么时候传值？
和所有C家族中的语言一样，Go中的所有东西都通过值来传递。也就是说， 函数总是会获得向它传递的东西的一份副本，就好像有一个赋值语句向它的形参赋值。 例如，将一个 int 值传入一个函数就会创建该 int 值的一份副本，而传入一个指针值则会创建该指针的一份副本，而不是它所指向的数据。 （关于它如何影响方法接收器的讨论见下一节。）
映射和切片值的行为就像指针一样：它们就是包含指向基本映射或切片数据的指针的描述符。 复制一个映射或切片会创建一个存储在接口值中的东西的一个副本。若该接口值保存了一个结构， 复制该接口值则会创建一个该结构的副本。若该接口值保存了一个指针， 复制该接口值则会创建一个该指针的副本，而且同样不是它所指向的数据。
为什么我的nil错误值不等于nil？
在底层，接口作为两个元素实现：一个类型和一个值。该值被称为接口的动态值， 它是一个任意的具体值，而该接口的类型则为该值的类型。对于 int 值3， 一个接口值示意性地包含(int, 3)。
只有在内部值和类型都未设置时(nil, nil)，一个接口的值才为 nil。特别是，一个 nil 接口将总是拥有一个 nil 类型。若我们在一个接口值中存储一个 *int 类型的指针，则内部类型将为 *int，无论该指针的值是什么：(*int, nil)。 因此，这样的接口值会是非 nil 的，即使在该指针的内部为 nil。
这种情况会让人迷惑，而且当 nil 值存储在接口值内部时这种情况总是发生， 例如错误返回：
func returnError() error {
var p *MyError = nil
if bad() {
p = ErrBad
}
return p //将总是返回一个非nil错误
}
如果一切顺利，该函数会返回一个 nil 的 p， 因此该返回值为拥有(*MyError, nil)的 error 接口值。这也就意味着如果调用者将返回的错误与 nil 相比较， 它将总是看上去有错误，即便没有什么坏事发生。要向调用者返回一个适当的 nil error，该函数必须返回一个显式的 nil：
func returnError() error {
if bad() {
return ErrBad
}
return nil
}
这对于总是在签名中使用 error 类型返回错误（正如我们上面做的）而非像 *MyError 这样具体类型的函数来说是个不错的主意，它可以帮助确保错误被正确地创建。 例如，即使 os.Open 返回一个 error， 若非 nil 的话，它总是具体的类型 *os.PathError。
对于那些描述，无论接口是否被使用，相似的情形都会出现。只要记住，如果任何具体的值已被存储在接口中， 该接口就不为 nil。
能否将[]T转换为[]interface{}？
不能直接转换，因为它们在内存中的表示并不相同。必须单独地将元素复制到目标切片。 下面的例子将 int 切片转换为 interface{} 切片：
t := []int{1, 2, 3, 4}
s := make([]interface{}, len(t))
for i, v := range t {
s[i] = v
}
为什么类型T不满足Equal接口？
考虑以下简单的接口，它表示一个可以将自身与另一个值进行比较的对象：
type Equaler interface {
Equal(Equaler) bool
}
以及此类型 T：
type T int
func (t T) Equal(u T) bool { return t == u } // does not satisfy Equaler
不像在一些多态类型系统中类似的情况，T 并未实现 Equaler。 T.Equal 的实参类型为 T，而非字面上所需要的类型 Equalar。
在Go中，类型系统并不提升 Equal 的实参，那是程序员的责任， 就以下类型 T2 所示，它实现了 Equaler：
type T2 int
func (t T2) Equal(u Equaler) bool { return t == u.(T2) } //满足Equaler
即使它不像其它的类型系统也好，因为在Go中任何满足 Equaler 的类型都能作为实参传至 T2.Equal，并在运行时我们必须检查该实参是否为 T2类型。一些语言将其安排在编译时以保证做到这一点。
一个相关的例子是另一种情形：
type Opener interface {
Open() Reader
}
func (t T3) Open() *os.File
在Go中，T3 并不满足 Opener，尽管它在另一种语言中可能满足。
在相同情况下，Go的类型系统确实为程序员做的更少， 子类型化的缺乏使关于接口满足的规则非常容易制订： 函数的名字和签名完全就是那些接口吗？Go的规则也容易高效地实现。 我们感觉这些效益抵消了自动类型提升的缺失。Go在某天应当采取一些泛型的形式， 我们期望会有一些方式来表达这些例子的想法，且也拥有静态检查。
如何保证我的类型满足某个接口？
可以通过尝试赋值来要求编译器检查类型 T 是否实现了接口 I：
type T struct{}
var _ I = T{} //确认T是否实现了I。
如果你希望接口的使用者显式地声明它们实现了它，你可以将一个带描述性名称的方法添加到该接口的方法集中：
type Fooer interface {
Foo()
ImplementsFooer()
}
然后类型必须实现 ImplementsFooer 方法成为 Fooer， godoc的输出中清晰地记录了事实和通告。
type Bar struct{}
func (b Bar) ImplemnetsFooer() {}
func (b Bar) Foo() {}
大部分代码无需使用这类约束，因为它们限制了实用程序的接口思想。 但有时候，它们也需要解决相似接口之间的歧义。