https://www.zhihu.com/question/364687707
在知乎上已经说了原因，不过只是讲官方的 spec，我们再来看看实现上具体为什么会是这样的。
package main
import "fmt"
func main() {
a := new(struct{})
b := new(struct{})
println(a, b, a == b)
c := new(struct{})
d := new(struct{
MQ 对于业务系统建模非常重要，是解决分离关注点、依赖反转、CQRS、最终一致等业务问题的重要法宝。
然而企业对于 MQ 中的数据管理却并不重视。从互联网企业发展的历程来看这个问题，最初 MQ 不是很可靠，大家不会把让特别重要的业务依赖 MQ，所以接入到 MQ
的业务事件并不多。总共也就两三个
topic，开发相应的系统对这些内容进行管理看起来没什么必要，甚至可能连详尽的业务信息都要从生产者的代码注释中去寻找。公司规模不大，这些都是可以接受的。
经历过 1Mb 小水管的朋友大概还记得当初火爆的 Flashget 的 Slogan：
> 下载的最大问题是什么——速度，其次是什么—
逻辑复杂的系统中，我们经常能看到“规则引擎”和“决策树”之类的东西。
在数据准备好的前提下，规则引擎和决策树都可以理解成在大宽表上进行决策的过程，两者进行逻辑运算需要较为统一的数据格式，即需要对不同来源的数据内容进行统一抽象。
在之前的文章中，我写过 一劳永逸接入所有下游数据系统
[http://xargin.com/integrate-downstream-data-system-all-in-one/]
，讲的便是复杂系统中对准备数据过程的一种抽象。这种抽象在方法论大湿们发明的概念中早有总结：Anti Corruption Layer
[https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer]
。你可以把它叫做 adapter，
依赖反转即 OOP 中的 SOLID 原则中的 D(Dependency Inversion Principle
[https://en.wikipedia.org/wiki/Dependency_inversion_principle])，最早么，是 Uncle Bob
提出的：
> The dependency inversion principle was postulated by Robert C. Martin and
同事给了一个挺有意思的程序：
package main
import (
"fmt"
"os"
"runtime/trace"
"sync"
"time"
)
var mlock sync.RWMutex
var wg sync.WaitGroup
func main() {
trace.Start(os.Stderr)
defer trace.Stop()
wg.Add(100)
for i := 0;
