在开始之前，希望你计算一下 Part1 共占用的大小是多少呢？
输出结果：
这么一算， Part1 这一个结构体的占用内存大小为 1+4+1+8+1 = 15 个字节。相信有的小伙伴是这么算的，看上去也没什么毛病
真实情况是怎么样的呢？我们实际调用看看，如下：
输出结果：
最终输出为占用 32 个字节。这与前面所预期的结果完全不一样。这充分地说明了先前的计算方式是错误的。为什么呢？
在这里要提到 “内存对齐” 这一概念，才能够用正确的姿势去计算，接下来我们详细的讲讲它是什么
有的小伙伴可能会认为内存读取，就是一个简单的字节数组摆放
上图表示一个坑一个萝卜的内存读取方式。但实际上 CPU 并不会以一个一个字节去读取和写入内存。相反 CPU 读取内存是 一块一块读取 的，块的大小可以为 2、4、6、8、16 字节等大小。块大小我们称其为 内存访问粒度 。如下图：
在样例中，假设访问粒度为 4。 CPU 是以每 4 个字节大小的访问粒度去读取和写入内存的。这才是正确的姿势
另外作为一个工程师，你也很有必要学习这块知识点哦 :)
在上图中，假设从 Index 1 开始读取，将会出现很崩溃的问题。因为它的内存访问边界是不对齐的。因此 CPU 会做一些额外的处理工作。如下：
从上述流程可得出，不做 “内存对齐” 是一件有点 "麻烦" 的事。因为它会增加许多耗费时间的动作
而假设做了内存对齐，从 Index 0 开始读取 4 个字节，只需要读取一次，也不需要额外的运算。这显然高效很多，是标准的 空间换时间 做法
在不同平台上的编译器都有自己默认的 “对齐系数”，可通过预编译命令 #pragma pack(n) 进行变更，n 就是代指 “对齐系数”。一般来讲，我们常用的平台的系数如下：
另外要注意，不同硬件平台占用的大小和对齐值都可能是不一样的。因此本文的值不是唯一的，调试的时候需按本机的实际情况考虑
输出结果：
在 Go 中可以调用 unsafe.Alignof 来返回相应类型的对齐系数。通过观察输出结果，可得知基本都是 2^n ，最大也不会超过 8。这是因为我手提（64 位）编译器默认对齐系数是 8，因此最大值不会超过这个数
在上小节中，提到了结构体中的成员变量要做字节对齐。那么想当然身为最终结果的结构体，也是需要做字节对齐的
接下来我们一起分析一下，“它” 到底经历了些什么，影响了 “预期” 结果
在每个成员变量进行对齐后，根据规则 2，整个结构体本身也要进行字节对齐，因为可发现它可能并不是 2^n ，不是偶数倍。显然不符合对齐的规则
根据规则 2，可得出对齐值为 8。现在的偏移量为 25，不是 8 的整倍数。因此确定偏移量为 32。对结构体进行对齐
Part1 内存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通过本节的分析，可得知先前的 “推算” 为什么错误？
是因为实际内存管理并非 “一个萝卜一个坑” 的思想。而是一块一块。通过空间换时间（效率）的思想来完成这块读取、写入。另外也需要兼顾不同平台的内存操作情况
在上一小节，可得知根据成员变量的类型不同，其结构体的内存会产生对齐等动作。那假设字段顺序不同，会不会有什么变化呢？我们一起来试试吧 :-)
输出结果：
通过结果可以惊喜的发现，只是 “简单” 对成员变量的字段顺序进行改变，就改变了结构体占用大小
接下来我们一起剖析一下 Part2 ，看看它的内部到底和上一位之间有什么区别，才导致了这样的结果？
符合规则 2，不需要额外对齐
Part2 内存布局：ecax|bbbb|dddd|dddd
通过对比 Part1 和 Part2 的内存布局，你会发现两者有很大的不同。如下：
仔细一看， Part1 存在许多 Padding。显然它占据了不少空间，那么 Padding 是怎么出现的呢？
通过本文的介绍，可得知是由于不同类型导致需要进行字节对齐，以此保证内存的访问边界
那么也不难理解，为什么 调整结构体内成员变量的字段顺序 就能达到缩小结构体占用大小的疑问了，是因为巧妙地减少了 Padding 的存在。让它们更 “紧凑” 了。这一点对于加深 Go 的内存布局印象和大对象的优化非常有帮
衍生类型，interface{} , map, [] ，struct等
map类似于java的hashmap，python的dict，php的hash array。
常规的for循环，可以用for k,v :=range m {}. 但在下面清空有一个坑注意：
著名的map[string]*struct 副本问题
结果：
Go 中不存在引用传递，所有的参数传递都是值传递，而map是等同于指针类型的，所以在把map变量传递给函数时，函数对map的修改，也会实质改变map的值。
slice类似于其他语言的数组（list，array），slice初始化和map一样，这里不在重复
除了Pointer数组外，len表示使用长度，cap是总容量，make([]int, len, cap)可以预申请 比较大的容量，这样可以减少容量拓展的消耗，前提是要用到。
cap是计算切片容量，len是计算变量长度的，两者不一样。具体例子如下：
结果：
分析：cap是计算当前slice已分配的容量大小，采用的是预分配的伙伴算法（当容量满时，拓展分配一倍的容量）。
append是slice非常常用的函数，用于添加数据到slice中，但如果使用不好，会有下面的问题：
预期是[1 2 3 4 5 6 7 8 9 10]， [1 2 3 4 5 6 7 8 9 10 11 12]，但实际结果是：
注意slice是值传递，修改一下：
输出如下：
== 只能用于判断常规数据类型，无法使用用于slice和map判断，用于判断map和slice可以使用reflect.DeepEqual，这个函数用了递归来判断每层的k，v是否一致。
当然还有其他方式，比如转换成json，但小心有一些异常的bug，比如html编码，具体这个json问题，待后面在分析。
Go中数值类型可细分为整数、浮点数、复数三种，每种都具有不同的大小范围和正负支持。
整型分为两大类
Go提供了有符号和无符号的整数类型，同时提供四种大小不同的整数类型。
取值范围
等价类型
特殊整型
int 和 uint 分别对应特定CPU平台的字长（机器字大小），大小范围在 32bit 或 64bit 之间变化，实际开发中由于编译器和硬件不同而不同。
进制转换
转换函数
使用注意
字节长度
Golang提供了两种精度的浮点数分别为 float32 和 float64 ，它们的算术规范由IEEE754浮点数国际标准定义，IEEE754浮点数标准被现代CPU支持。
float32 类型的浮点数可提供约6个十进制数的精度， float64 类型的浮点数可提供约15个十进制数的精度。通常会优先选择使用 float64 ，因为 float32 累计计算误差会比较容易扩散。
计算机中复数（complex）由两个浮点数表示，一个表示实部（real）一个表示虚部（imag）。
Go语言中复数的值由三部分组成 RE + IMi ，分别是实数部分 RE 、虚数部分 IM 、虚数单位 i ， RE 和 IM 均为 float 。
Go语言提供两种类型的复数，分别是 complex64 即32位实数和虚数， complex128 即64位实数和虚数， complex128 为复数的默认类型。
复数声明
z 表示复数的变量名， complex128 表示复数类型， complex() 内置函数用于为复数赋值。 x 和 y 分别表示构成该复数的两个 float64 类型的值， x 为实部， y 为虚部。
简写形式
对于 z 值可通过内置函数 real(z) 获取该复数的实部，使用 imag(z) 获取虚部。
