对比于其他语言的程序，Go语言的跨平台能力是真的强，拿.Net和JAVA来说吧，.Net在.Net core出现之前是不能跨平台的，只能在windows上编译运行，即使是.net core出现以后，跨平台的程序也是相当的麻烦。而java虽然一直都可以跨平台，但是运行JAVA程序的机器上也必须要有JAVA程序运行环境JRE。而相对于Go程序，跨平台就简单的多了，只需要在编译指定目标程序运行的架构和环境即可编译出指定操作系统和架构的程序。
北川羌族网站建设公司创新互联,北川羌族网站设计制作，有大型网站制作公司丰富经验。已为北川羌族上1000+提供企业网站建设服务。企业网站搭建\成都外贸网站制作要多少钱，请找那个售后服务好的北川羌族做网站的公司定做！
以上是指定了go的环境变量后执行的go build命令进行目标程序的构建，这种方式会一直生效的，如果不让他一直生效，可以在构建的时候临时指定环境变量，下面以window的环境为例，来介绍临时指定环境变量的方式构建可以在Linux环境下运行的可执行程序：
可以根据不同的架构和操作系统将其编写为不同的.bat的可执行文件放置在程序的根目录，Linux的和MAC的也一样编写成脚本文件放置在程序的根目录，这样在构建的时候就不用再敲命令了，直接运行脚本就可以了。
Java程序编译打包后为war包或者是java包，必须执行java -jar 命令或者将其放置到tomcat的指定目录下，运行tomcat程序。而Go语言编写的程序最终为可执行的文件（window下编译出的是.exe的可执行文件），只需要将其赋予可执行的权限就可以直接运行了。
构建JAVA程序的镜像需要指定java的基础镜像，否则就需要在镜像中安装java的运行环境了，下面展示的是构建的一个JAVA程序的镜像，构建出来镜像的体积相对比较大
而Go程序制作出的镜像就不需要安装任何的依赖环境，因为他在打包的时候就已经将依赖的包一块打包到一起了
拿着这个镜像就可以到处运行了。
通过对比我们可以发现，如果没有之前的技术和业务的积累，重新开发一个新的项目，使用go去开发无疑是最容易上手的，所以现在很多公司都使用go进行开发，也逐渐将其他语言的项目逐步的用go语言进行改造。其实用什么语言不重要，合适的才重要，开发项目在选择语言的时候也会综合多方面来考虑选择合适的语言和架构，毕竟很多公司都不是搞研究的，都需要项目来赚钱，所以开发的速度、客户的满意度、项目交付的时间才是驱动公司技术的主要因素。
我们个人也应该不断完善自己的技术栈，不应该太依靠某种语言，最重要的还是自己的架构思想和底层架构知识，只有掌握了这些才能够不被 社会 和公司“优化”。
1. 部署简单
Go
编译生成的是一个静态可执行文件，除了glibc外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。
2. 并发性好
Goroutine和channel使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个Go应用也能有效的利用多个CPU核，并行执行的性能好。
3. 良好的语言设计
从学术的角度讲Go语言其实非常平庸，不支持许多高级的语言特性;但从工程的角度讲，Go的设计是非常优秀的：规范足够简单灵活，有其他语言基础的程序员都能迅速上手。更重要的是
Go 自带完善的工具链，大大提高了团队协作的一致性。
4. 执行性能好
虽然不如 C 和 Java，但相比于其他编程语言，其执行性能还是很好的，适合编写一些瓶颈业务，内存占用也非常省。
自编译缩小体积的方法如下。
1、采用交叉编译的方式，使用Go语言的编译工具，将代码编译成特定平台的可执行文件。
2、采用精简模式编译，去除不必要的代码和功能，减少可执行文件的体积。
3、使用压缩工具，对可执行文件进行压缩，减少可执行文件的体积。
在开始之前，希望你计算一下 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 的内存布局印象和大对象的优化非常有帮
