地址 数据
0x0004(高地址) 0x44
0x0003 0x33
0x0002 0x22
0x0001(低地址) 0x11
(2)小端模式存储（存储地址为16位）
地址 数据
0x0004(高地址) 0x11
0x0003 0x22
0x0002 0x33
0x0001(低地址) 0x44
在前面也简单阐述了大小端序的定义并结合简单实例来说明，接下来会给出详细实例来说明：
1、大端序(Big-Endian):或称大尾序
一个类型: int32 的数 0X0A0B0C0D的内存存放情况
数据是以8bits为单位
2、小端序(little-endian):或称小尾序
比如0x00000001
大端序：内存低比特位 00000000 00000000 00000000 00000001 内存高比特位
小端序：内存低比特位 10000000 00000000 00000000 00000000 内存高比特位
其实在前面罗列出那么东西，最终是为了接下来讲述的在golang中涉及到网络传输、文件存储时的选择。一般来说网络传输的字节序，可能是大端序或者小端序，取决于软件开始时通讯双方的协议规定。TCP/IP协议RFC1700规定使用“大端”字节序为网络字节序，开发的时候需要遵守这一规则。默认golang是使用大端序。详情见golang中包encoding/binary已提供了大、小端序的使用
输出结果：
16909060 use big endian:
int32 to bytes: [1 2 3 4]### [0001 0002 0003 0004]
bytes to int32: 16909060
16909060 use little endian:
int32 to bytes: [4 3 2 1] ### [0004 0003 0002 0001]
bytes to int32: 16909060
在RPCX框架中关于RPC调用过程涉及的传递消息进行编码的，采用的就是大端序模式
golang保存二进制文件会有大小端问题。
这个二进制文件的确有Big Endian 和Little Endian的问题，这个与CPU指令体系有关，不过不用操心，像JPEG就是Big Endian，其编解码就都是按照这个约定来完成的，没有平台问题，也没有大小端的问题。
编译centos上的可执行文件的时候需要交叉编译。golang的交叉编译很容易，你的情况的话用下面这条命令，GOOS=linux GOARCH=amd64 go build ./文件。
golang描述：
Go的语法接近C语言，但对于变量的声明有所不同。Go支持垃圾回收功能。Go的并行模型是以东尼·霍尔的通信顺序进程（CSP）为基础。
采取类似模型的其他语言包括Occam和Limbo，但它也具有Pi运算的特征，比如通道传输。在1.8版本中开放插件（Plugin）的支持，这意味着现在能从Go中动态加载部分函数。
与C++相比，Go并不包括如枚举、异常处理、继承、泛型、断言、虚函数等功能，但增加了 切片(Slice) 型、并发、管道、垃圾回收、接口（Interface）等特性的语言级支持。Go 2.0版本将支持泛型，对于断言的存在，则持负面态度，同时也为自己不提供类型继承来辩护。
