本文索引 語言變化 數字字面量 越界索引報錯的完善 工具鏈改進 GOPROXY GOSUMDB GOPRIVATE 標準庫的新功能 判斷變數是否為0值 錯誤處理的革新 Unwrap Is As golang1.13發佈已經有一個月了，本文將會列舉其中幾個較為重要的特性。我們將會從語言變化、庫變化以及 ...
本文索引
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，則會報錯。
proxy的好處自然不用多說，它可以使國內開發者暢通無阻地訪問某些國內環境無法獲取的包。更重要的是預設的proxy是官方提供和維護的，比起第三方方案來說安全性有了更大的保障。
GOSUMDB
這個變數實際上相當於指定了一個由官方管理的線上的go.sum資料庫。具體介紹之前我們先來看看golang是如何驗證packages的：
- go get下載的package會根據go.mod文件和所有下載文件分別建立一個hash字元串，存儲在go.sum文件中；
- 下載的package會被cache，每次編譯或者手動go mod verify時會重新計算與go.sum中的值比較，出現不一致就會報安全錯誤。
這個機制是建立在本地的cache在整個開發生命周期中不會變動之上的（因為依賴庫的版本很少會進行更新，除非出現重大安全問題），上述機制可以避免他人誤更新依賴或是本地的惡意篡改，然而現在更多的安全問題是發生在遠程環境的，因此這一機制有很大的安全隱患。
好在加入了GOSUMDB，它的預設值為“sum.golang.org”，國內部分地區無法訪問，可以改為“sum.golang.google.cn”。現在的工作機制是這樣的：
- go get下載包並計算校驗和，計算好後會先檢查是否已經出現在go.sum文件中，如果沒有則去GOSUMDB中檢查，校驗和一致則寫入go.sum文件；否則報錯
- 如果對應版本的包的校驗和已經在go.sum中，則不會請求GOSUMDB，其餘步驟和舊機制一樣。
安全性得到了增強。
GOPRIVATE
最後要介紹的是GOPRIVATE，預設為空，你可以在其中使用類似Linux glob通配符的語法來指定某些或某一類包不從proxy下載，比如某些rpc套件自動生成的package，這些在proxy中並不會存在，而且即使上傳上去也沒有意義，因此你需要把它寫入GOPRIVATE中。
還有一個與其類似的環境變數叫GONOPROXY，值的形式一樣，作用也基本一樣，不過它會覆蓋GOPRIVATE。比如將其設為none時所有的包都會從proxy進行獲取。
從這些變化來看go團隊始終在尋找一種能細粒度控制的統一的包管理解決方案，雖然目前和npm、pypi還有巨大的差距，但仍不失為成功道路上的堅實一步。
標準庫的新功能
每次新版本發佈都會給標準庫帶來大把的新功能新特性，這次也不例外。
本節會介紹一個小的新功能，以及一個重要的新變化。
判斷變數是否為0值
golang中任何類型的0值都有明確的定義，然而遺憾的是不同的類型0值不同，特別是那些自定義類型，如果你要判斷一個變數是否0值那麼將會寫出複雜繁瑣而且擴展困難的代碼。
因此reflect中新增了這一功能簡化了操作：
package main
import (
"fmt"
"reflect"
)
func main() {
a := 0
b := 1
c := ""
d := "a"
fmt.Println(reflect.ValueOf(a).IsZero()) // true
fmt.Println(reflect.ValueOf(b).IsZero()) // false
fmt.Println(reflect.ValueOf(c).IsZero()) // true
fmt.Println(reflect.ValueOf(d).IsZero()) // false
}當然，反射一勞永逸的代價是更高的性能消耗，所以具體取捨還要參照實際環境。
錯誤處理的革新
其實算不上革新，只是對現有做法的小修小補。golang團隊始終有覺得error既然是值那就一定得體現value的equal操作的怪癖，所以整體上還是很怪。
首先要介紹錯誤鏈（error chains）的概念。
在1.13中，我們可以給error實現一個Unwrap的方法，從而實現對error的包裝，比如：
type PermError {
os.SyscallError
Pid uint
Uid uint
}
func (err *PermError) String() string {
return fmt.Sprintf("permission error:\npid:%v\nuid:\ninfo:%v", err.Pid, err.Uid, err.SyscallError)
}
func (err *PermError) Error() string {
return err.String()
}
// 重點在這裡
func (err *PermError) Unwrap() error {
return err.SyscallError
}假設我們包裝了一個基於SyscallError的許可權錯誤，包括了所有因為許可權問題而觸發的error。String和Error方法都是常規的自定義錯誤中會實現的方法，我們重點看Unwrap方法。
Unwrap字面意思就是去包裝，也就是我們把包裝好的上一層錯誤重新分離出來並返回。os.SyscallError也實現了Unwrap，於是你可以繼續向上追溯直達最原始的沒有實現Unwrap的那個error為止。我們稱從PermError開始到最頂層的error為一條錯誤鏈。
如果我們用→指向Unwrap返回的對象，會形成下麵的結構：
PermError → os.SyscallError → error
還可以出現更複雜的結構：
A → Err1 ___________
|
V
B → Err2 → Err3 → error
這樣無疑提升了錯誤的表達力，如果不想自己單獨定義一個錯誤類型，只想附加某些信息，可以依賴fmt.Errorf：
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == newErr.(interface {Unwrap() error}).Unwrap()fmt.Errorf新的占位符%w只能在一個格式化字元串中出現一次，他會把error的信息填充進去，然後返回一個實現了Unwrap的新error，它返回傳入的那個error。另外提案里的Wrapper介面目前還沒有實現，但是標準庫用了我在上面的做法暫時實現了Wrapper的功能。
因為錯誤鏈的存在，我們不能在簡單的用等於號基於判斷基於值的error了，但好處是我們現在還可以判斷基於類型的error。
為了能繼續讓error表現自己的值語義，errors包里增加了Is和As以及輔助它們的Unwrap函數。
Unwrap
errors.Unwrap會調用傳入參數的Unwrap方法，As和Is使用它來追溯整個錯誤鏈。
像上一小節的代碼就可以簡化成這樣：
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
sysErr == errors.Unwrap(newErr).Unwrap()Is
我們提到等於號的比較很多時候已經不管用了，有的時侯一個error只是對另一個的包裝，當這個error產生時另一個也已經發生了，這時候我們只需要比較處於上層的error值即可，這時候你就需要errors.Is幫忙了：
newErr := fmt.Errorf("permission error:\npid:%v\nuid:\ninfo:%w", pid, uid, sysErr)
errors.Is(newErr, sysErr)
errors.Is(newErr, os.ErrExists)你永遠也不知道程式會被怎樣擴展，也不知道error之間的關係未來會怎樣變化，因此總是用Is代替==是不會犯錯的。
不過凡事總有例外，例如io.EOF就不需要使用Is去比較，因為它程式意義上算不上是error，而且一般也不會有人包裝它。
As
除了傳統的基於值的判斷，對某個類型的錯誤進行處理也是一個常見需求。例如前文的A，B都來自error，假設我們現在要處理所有基於這個error的錯誤，常見的辦法是switch進行比較或者依賴於基類的多態能力。
顯而易見的是switch判斷的做法會導致大量重覆的代碼，而且擴展困難；而在golang里沒有繼承只有組合，所以有運行時多態能力的只有interface，這時候我們只能藉助錯誤鏈讓errors.As幫忙了：
// 註意As的第二個參數只能是你需要判斷的類型的指針，不可以直接傳一個nil進去
var p1 *os.SyscallError
var p2 *os.PathError
errors.As(newErr, &p1)
errors.As(newErr, &p2)如果p1和p2的類型在newErr所在的錯誤鏈上，就會返回true，實現了一個很簡陋的多態效果。As總是用於替代if _, ok := err.(type); ok這樣的代碼。
當然，上面的函數一方面讓你少寫了很多代碼，另一方面又嚴重依賴反射，特別是錯誤鏈很長的時候需要反覆追溯多次，所以這裡有兩條忠告：
- 不要過渡包裝，沒什麼是加間接層解決不了的，但是中間層太多不僅影響性能也會幹擾後續維護；
- 如果你實在在意性能，而且保證不存在對現有error的擴展（例如io.EOF），那麼使用傳統方案也無傷大雅。
就個人而言我不認為新的錯誤處理方法解決了什麼本質的問題，但作為邁出嘗試的第一步，還是值得肯定的。
