大家好，我是煎魚。

前兩天有讀者提醒我關注 Go 大當家 Russ Cox 發起的 Go 工具鏈中的遙測（telemetry in the Go toolchain^[1]）討論。不看不知道，一看下一跳。

今天來分享一些看法和信息。

為什么要收集數據

Russ Cox（下稱 rsc）發起的背景是 Go 開源項目的開發者（例如：Go 核心團隊）在沒有遙測的情況下，會遇到如下的場景：

• 需要依賴外部的錯誤報告（例如：GitHub issues）來了解他們自己寫的軟件如何在意料之外發生異常。
• 調研用戶是如何使用自己寫的開源項目，是否符合預期，又或是創造出了新的用法。

這么一聽，好像和我們平時的認知也差不多。換位思考一下，Go 核心開發者就比較頭疼了。認為這兩種方式作用都很有限，達不到他們想要的效果。

因此想要抽樣收集用戶的使用數據，便于 Go 團隊更好的開發和調研。

被局限的例子

錯誤報告

我們會提交錯誤報告，一般只會出現在類似 ”我們預期這事應該能正常跑起來，但你居然沒有跑起來“ 的場景下。在現有的情況下，如果程序在不影響正確性的情況下出現了錯誤行為，用戶就不可能注意到。

反之，如果實施了遙測（收集數據），開發者就可以通過 Go 工具鏈收集上來的統計數據發現異常。（有抓手了）

具體案例，rsc 說明了在 Go 1.14 版本的發布中，對 macOS Go 發行版的構建方式進行了更改，造成使用 net 包（使用 cgo ）編譯任何程序都需要安裝 Xcode。

這不是他們所預期的，是意外之外的。

但在發生這問題的三年內，沒有任何人報告過這個錯誤。用戶只是簡單地接受了這是必要的安裝。

直至近期，Go 核心團隊排查其他問題，才發現有這個坑。如果有遙測收集使用數據，那這個問題完全可以被避免。

調查用戶

Go 開發團隊想知道 ”用戶想用 Go 做什么“，或是想基于數據用于做一些新老功能版本的決策。

但現在開源項目普遍都很難，他們只能發調查報告，就像我們每年填的 Go 開發者調查報告，就是這個目的。

Go Developer Survey 2022 Q2 Results

但是 rsc 對調查報告也是不滿足的。因為只是一個小樣本，效果有限。且需要大量的用戶選項和回復才能得到相對準確的測量結果，比較浪費時間。

具體案例，rsc 舉例 go 開源項目，經常會在新版本增加開關，再逐步去掉的做法。像最近宣布 Go 1.21 起將不再支持 macOS1.13/1.14，馬上就收到了用戶的反饋，要求保留。

如果有遙測收集使用數據，這個問題將有具體的數據作為決策支撐。就跟我們平時前端同學，會收集用戶端的操作系統和版本作為是否支持 IE 的依據等。

想收集什么數據

說要收集，會在哪收集，具體要收集什么呢？會收集的地方主要是 Go 工具鏈，例如：Go 命令、Go 編譯器、Gopls 等地方。

收集的數據，將至少包含工具鏈的基本信息，例如：

• Go 工具鏈版本。
• 是什么操作系統和架構構建的。
• 主機操作系統版本（例如：Windows8）。
• Go 工具鏈使用的其他工具的粗略信息，例如本地 C 編譯器（例如：gcc 2.95）。

不會包含任何形式的身份信息，例如：

• 沒有用戶登錄。
• 沒有機器 ID。
• 沒有 MAC 地址。
• 沒有 IP 地址，沒有 IP 地址前綴。
• 沒有地理位置信息
• 沒有隨機生成的偽 ID，沒有其他種類的標識符。

收集的數據會在 Go 網站上公布，定時展示統計圖表等，便于所有 Go 開發者審閱和查看。

社區爭議滿滿

絕大部分開發者是沒有直接同意 rsc 這么干的，主流的回復分成了三派。

大致如下：

• 直接拒絕，覺得這是在侵犯個人隱私。
• 建議做成可選項，例如：限時選擇上報、選擇上報（使用 Go 時彈出 Cookie 彈窗、拋出異常時彈出彈窗）等。
• 直接抵制，認為 Go 重蹈 Google 后路。用詞強烈，要求 rsc 公開道歉，表示這是推下懸崖的選擇，降低了信任。

整體來看，參與討論的 Go 開發者都非常關注 ”隱私“ 的問題。更建議做成可選項，也就是用戶選擇上報。

如果以后寫 Go 的時候彈出 Cookie 彈窗還是很 ”有趣“的吧（doge。

總結

Go 核心團隊本身的出發點是好的，他們在維護 Go 開源項目時，經常拿不到一些關鍵數據和信息，導致在做決策時很糾結。

這在業務應用中，比較常見的是在前端埋探針，獲取你的客戶端信息等。但這是閉源的，整體風險沒有那么大。

但對于開源項目來講，這是開源的，受到所有人的檢閱。這類隱私數據收集，在臺面上直接默認上報肯定是不可行的，爭議會比較大。

從結果來看，由于沒有更多新的內容，比較情緒化，這個討論已經被中止。未來如果做，我猜更大概率是做成可選項，詢問式。