golang1.13发布已经有一个月了，本文将会列举其中几个较为重要的特性。我们将会从语言变化、库变化以及工具链的改进这三方面逐个介绍新版本中引入的新特性。
语言变化go团队一直承诺1.x版本的向前兼容，所以虽然1.13作为第一个开始向go2过渡的版本，其引入的语言变化是极少的，主要只有这两点：更多的数字字面量和改进的panic信息。
数字字面量数字字面量是大家再熟悉不过的东西了，比如100，0.99，1.等。
然而奇怪的是，1.13之前的golang仅支持10进制和16进制的字面量，而在其它语言中广泛支持的二进制和八进制却不受支持。例如下面的代码是无法编译的：
fmt.Println(0b101) fmt.Println(0o10)在go1.13中上述字面量语法已经被支持了你可以通过0b或0B前缀来表明一个二进制数字的字面量，以及用0o和0O来表明八进制字面量。值得注意的是虽然两种写法都可以，但是gofmt默认会全部转换为小写，所以我更推荐使用0b和0o使你的代码风格尽量统一。
数字字面量的另一个变化就是引入了16进制浮点数的支持。
16进制浮点数是按照16进制来表示浮点数的方法，需要注意的是这里指的不是将浮点数表示为对应二进制值的16进制形式，而是形式如下的16进制数字：
0X十六进制整数部分.十六进制小数部分p指数其中整数和小数部分和普通浮点字面量一样可以省略，省略的部分默认为0。p+指数的部分不可省略，指数可以有符号，它的值是2的指数。
一个16进制浮点字面量最终的结果，假设p之前的部分的值为a，p后的指数是b，最终的值如下：a * 2^b。
看上去和科学计数法很像，事实上也就是把e换成了p，指数计算从10变为了2。另外因为是每16进1，所以0x0.1p0看上去像0.1，然而它表示的是1/16，而0x0.01p0则是1/16的1/16，初见会不太直观，但是习惯后就不会有什么问题了。举点例子：
二进制和八进制字面量是比较常用的，那16进制浮点数呢？答案是更高的精度和统一的表达。
0x0.1p0表示的十进制值是0.0625，而0x0.01p0是0.00390625，已经超过了float32的精度范围，所以16进制浮点字面量可以在有限的精度范围内表示更精确的数值。统一表达自然不用多解释，习惯16进制表达的开发者更乐于使用类似形式。
具体的示例可以参考。
最后对于数字字面量还有一个小小的改进，那就是现在可以用下划线分隔数字增加可读性。举个例子：
fmt.Println(100000000) fmt.Println(1_0000_0000) fmt.Println(0xff_ff_ff)分隔符可以出现在任意位置，但是像0x之类的算是一个完整的符号的中间不可以插入下划线，分隔符之间字符的数量没有规定必须相等，但为了可读性最好按照现有的习惯每3个数字或四个数字进行一次分隔。
越界索引报错的完善虽然我将其归为语言变化，但事实上将其定义为运行时改进更为恰当。
众所周知golang对数组和slice的越界引用是0容忍的，一旦越界就会panic，例如下面的例子：
package main import "fmt" func main() { arr := [...]int{1,2,3,4,5} for i := 0; i <= len(arr); i++ { fmt.Println(arr[i]) } }如果运行这个程序那么你会收到一个不短的抱怨：
这里的例子很简单，所以调用堆栈信息追溯起来不是很困难，可以方便得定位问题，但如果调用链较深或者你处于一个高并发程序之中，事情就变得麻烦了，要么依赖日志调试并最终分析排除大量杂音来定位问题，要么依赖断点进行单步调试，无论哪种都需要耗费大量的精力，而核心问题只是我们想直到为什么会越界，再浅一步，我们有时候或许只要知道导致越界的值就可以大致确定问题的原因，遗憾的是panic提供的信息中不包含上述内容，直到golang1.13。
现在golang会将导致越界的值打印出来，无疑是雪中送碳：
当然，panic信息再完善也不是灵丹妙药，完善的单元测试和严谨的工作态度才是bug最好的预防针。
工具链改进语言层面的变动不是很大，但工具链就不一样了，除了去除了godoc程序，最大的变化仍旧集中在go modules上。
这次golang加入了三个环境变量来共同控制modules的行为，下面分别进行介绍。
GOPROXY其实这个变量在1.12中就引入了，这次为其加上了默认值https://proxy.golang.org,direct，这是一个逗号分隔的列表，后面两个变量的值和它相同，其中direct表示不经过代理直接连接，如果设置为off，则进制下载任何package。
在go get等命令获取package时，会从左至右依次查找，如果都没有找到匹配的package，则会报错。