2、var arr []int 这时arr就是一个slice 切片 。
3、数组中的元素可以是任何数据类型，包括值类型和引用类型，但是 不能混用 。
4、数组创建后，如果没有赋值，有默认值如下：
数值类型数组： 默认值为 0
字符串数组： 默认值为 ""
bool数组： 默认值为 false
5、使用数组的步骤：
(1)声明数组并开辟空间
(3)给数组各个元素赋值
(3)使用数组
6、数组的下标是从0开始的。
7、数组下标必须在指定范围内使用，否则报panic:数组越界，比如var arr [5]int的有效下标为0~4.
8、Go的数组属于 值类型 ，在默认情况下是 值传递 ，因此会进行值拷贝。 数组间不会相互影响。
9、如想在其他函数中去修改原来的数组，可以使用 引用传递 (指针方式)。
10、长度是数组类型的一部分，在传递函数参数时，需要考虑数组的长度，看以下案例：
题1：编译错误，因为不能把[3]int类型传递给[]int类型，前者是数组，后者是切片；
题2：编译错误，因为不能把[3]int类型传递给[4]int类型；
题3：编译正确，因为[3]int类型传给[3]int类型合法。
在公司项目中看到关于钱的数据在接口展示、添加修改的各种情况下结构体中相应字段用的都是string类型。觉得不太合理，因此查阅了一些资料，整理如下。
在网上搜到一篇博客:
在程序计算中涉及到钱的时候，为什么要用Decimal而不是Float
博客中介绍，如果用float类型再转为decimal类型时会造成精度丢失。转为string后再转为decimal则可以解决问题，保证精度。看着好像是很完美的回答了我想要了解的问题，但仔细一看用的语言是python，于是我便亲自试了下：
结果确实如此，但看版本是2.7，我怀疑是不是python2.7版本落后，因此存在问题，于是又换了python3，再次测试：
结论依然是一样。好吧，证实了，对于python确实应该先转为string再转为decimal。
但是，python是这样，难道go也是这样吗，于是我又开始了进一步测试：
go中decimal使用第三方库
这里是直接用float64转为decimal，并没有通过string中转，结果输出如下：
乍一看，看着好像是精度丢失了似的，但是对比后我们发现，float64和decimal前后都是一致的，也就是说float64转为decimal之后，保持了原样。那些看起来小数点后位数很多的结果，是因为float64浮点类型计算产生的问题，跟转换并没有关系。
为了验证这一结论，我又写了下面的测试：
不使用浮点类型相加，而用decimal类型相加，这样输出结果果然没问题了：
因此我们可以得出结论：对于go语言，在把float转换为decimal类型时，并不需要像python一样通过string中转，也依然可以保持精度。进一步，我们也可以想到上面的问题，对于钱，在结构体字段中，我们完全可以直接使用float类型，并不需要用string类型。而且好处时，使用float数值类型，无论对于前端还是后端，在进行数值范围验证的时候，会更方便，不必把string转为float后再验证了。
上面提到了decimal包，我们这里简单看下，里面的常用的方法：
定义decimal的几种方式：
decimal数值运算
比较：
我们再看下浮点精度运算不准确的原因，这篇文章讲解的比较细
浮点精度（float、double）运算不精确的原因
精度运算不准确这是为什么呢？我们接下来就需要从计算机所有数据的表现形式二进制说起了。如果大家很了解二进制与十进制的相互转换，那么就能轻易的知道精度运算不准确的问题原因是什么了。
接下来我们看一个简单的例子 2.1 这个十进制数转成二进制是什么样子的。
落入无限循环结果为 10.0001100110011........ ， 我们的计算机在存储小数时肯定是有长度限制的，所以会进行截取部分小数进行存储，从而导致计算机存储的数值只能是个大概的值，而不是精确的值。从这里看出来我们的计算机根本就无法使用二进制来精确的表示 2.1 这个十进制数字的值，连表示都无法精确表示出来，计算肯定是会出现问题的。
1、为什么数值表示用decimal 不用double
https://blog.csdn.net/a13766750034/article/details/101566632
2、在程序计算中涉及到钱的时候，为什么要用Decimal而不是Float
https://blog.csdn.net/weixin_43946756/article/details/87562619
3、MySQL数据类型DECIMAL用法
https://www.cnblogs.com/owenma/p/7097602.html
4、浮点精度（float、double）运算不精确的原因
https://blog.csdn.net/marco__/article/details/102515668
