9 月 8 日，Go 語言社區發布 2022 年第二季度開發者調查報告，本次調研覆蓋 5752 位受訪開發者，主題涉及他們在使用 Go 1.18 全新功能特性（包括泛型、安全工具和工作區）時的真實感受，以下是本次報告的重要內容。

泛型已經得到迅速接納。大多數受訪者都知道 Go 1.18 版本中引入了泛型，約四分之一受訪者稱已經在實際代碼中使用泛型。大多數開發者對泛型的發布贊賞有加，但也有部分受訪者發現目前的泛型設計限制太多。

Fuzzing 對大多數 Go 開發者來說仍是新鮮事物。Go 新版本內置的模糊測試在知名度上遠遠不及泛型，受訪者也不確定為什么或者何時需要使用模糊測試。

第三方依賴項成為最重要的安全問題。目前，受訪者稱如何避免包含已知漏洞的依賴項成為安全工作中的最大挑戰。總體而言，安全工作往往缺乏計劃、也沒有明確的回報，所以工具開發者應當盡可能自審自查，幫助開發者節約時間和精力。

我們的新功能發布工作還可以做得更好。關注 Go 官方博客的開發者一般對新版本的變化比較熟悉，但隨機抽樣的受訪者則不太了解最新版本的情況。因此我們要么應該在博文以外再開拓新的 Go 生態消息渠道，要么更努力地廣泛分享博文內容。

錯誤處理仍是個難題。隨著泛型的發布，受訪者在使用 Go 時面臨的最大難題變成了如何處理錯誤。總體來看，大家對 Go 語言的滿意度仍然很高，我們發現受訪者使用 Go 語言的方式并沒有明顯變化。

調查結果解讀

在本文中，我們將通過一系列圖表來解讀此番調查。所有圖表均采用相同格式，標題部分是向受訪者們提出的具體問題。除非另有說明，否則各問題均為單選形式，受訪者只能選擇其一。圖表的副標題部分，會標注是否為多選問題或開放性問題。

對于開放性問題，Go 團隊成員認真閱讀并手動整理了受訪者們的意見。大家對于這類問題的回應多種多樣，因此我們挑選了最具共性的前十大主題，其余主題則被歸類為“其他”。

為了幫助大家了解每條結論的證據權重，我們使用誤差線來表示響應意見的 95% 置信區間：條形較窄，則表示信心越強。有時，可能有多條響應意見的誤差線彼此重疊，意味著這些響應的相對順序并不具備統計學意義（或者說這些意見之間相互綁定）。各圖表的右下角為圖表中受訪者者人數，形式為“n= 受訪者人數”。

泛型

支持類型參數（即泛型）的 Go 1.18 發布之后，我們希望大家如何看待和采用這項新功能，并確定使用泛型時的常見挑戰或障礙。

絕大多數受訪者（86%）都知道 Go 1.18 版本引入了泛型。雖然我們預計這個比例會超過一半，但沒想到有這么高。我們還發現，約四分之一受訪者已經開始在 Go 代碼中使用泛型（26%），其中 14% 表示是在生產或已發布的代碼中使用。大多數受訪者（54%）并不抵觸泛型，只是目前還沒開始使用。** 另有 8% 的受訪者有意在 Go 中使用泛型，但出于種種原因而暫未行動。

是什么阻止了一些開發人員使用泛型？困擾大多數受訪者的其實就兩個理由：首先，30% 的受訪者表示他們發現現有泛型實現仍有諸多限制，例如不支持參數化方法、類型推斷和類型切換等。受訪者表示，這些問題限制了泛型的可用空間，或者導致泛型代碼過于冗長。

第二個理由則是某些依賴項尚不支持泛型——其中最典型的例子是 linter，此外還有仍在使用的早期 Go 版本，或者尚不提供 Go 1.18 包（26%）的 Linux 發行版等。12% 的受訪者則是因為學習曲線陡峭或說明文檔不充分而選擇放棄。

除了這些重要因素，受訪者還反饋了一些相對不太常見、但仍有意見的阻礙，如下圖所示。這里，我們僅列出已經在使用泛型，或者曾嘗試使用泛型但未能成功的受訪者。

我們還詢問了嘗試用過泛型的受訪者，希望了解他們的感受。令人振奮的是，10% 的受訪者表示泛型確實簡化了自己的代碼、降低了代碼重復度。除了高度贊賞之外，其他受訪者也普遍（43%）對泛型給予積極評價；相比之下，只有 6% 的受訪者對泛型表達了負面評價或感受。

與之前提到的使用挑戰相似，近三分之一受訪者表示 Go 的泛型實現限制太多。

Go 團隊正參考這些結果，研究是否或如何放寬這些限制。

? 安全性

經歷了 2020 年的 SolarWinds 漏洞之后，安全軟件開發實踐再次受到關注。Go 團隊也在優先考慮安全保障問題，包括建立軟件物料清單（SBOM）的配套工具、模糊測試以及最近推出的漏洞掃描。為了達成目標，本次調查特別詢問了關于軟件開發安全實踐和挑戰的問題，特別是：

Go 開發者目前在使用哪些類型的安全工具？

Go 開發者如何發現和解決漏洞？

要編寫出安全的 Go 軟件，最大的挑戰是什么？

調查結果表明，雖然靜態分析工具得到了廣泛應用（65%），但只有少數受訪者在使用這些工具發現漏洞（35%），或者以其他方式提高代碼安全性（33%）。受訪者們表示，安全工具主要運行在 CI/CD 過程（84%），只有少數開發者會在開發期間運行這些工具（22%）。

這與我們團隊進行的其他安全研究一致，即安全掃描大多集中在 CI/CD 期間，而這時才關注安全問題其實為時已晚。更理想的方法，應該是在構建之前就知曉依賴項是否存在漏洞、驗證版本更新是否解決了這些漏洞。等到 CI 針對 PR 運行完整測試時，隱患往往已經難以剔除。

我們還向受訪者詢問了他們在安全開發軟件時的最大挑戰。目前最常見的難題是如何評估第三方庫的安全性（57%）， 其實主題漏洞掃描器（例如 GitHub 的 dependabot 或者 Go 團隊的 govulncheck）就能很好地完成任務。

其他反饋意見則為新工具提供了發展空間：受訪者們表示，他們在編寫代碼并驗證成果是否存在漏洞時，往往很難全流程遵循最佳實踐。

模糊測試是提高應用程序安全性的另一種好辦法，但大多數受訪者似乎對此還不熟悉。只有 12% 的受訪者在實際工作中用過模糊測試，5% 的受訪者稱已經在使用 Go 內置模糊測試工具。

在“為什么會感覺模糊測試難以使用”的開放性問題中，我們發現影響最大的并非技術因素：占比最高的三個答案分別是“不了解如何使用模糊測試”（23%）、“沒時間進行模糊測試或者其他安全保障工作”（22%）、“沒法以符合預期的方式和時間進行模糊測試”（14%）。

這些發現表明，我們還需要投入精力幫助開發者了解模糊測試的價值、模糊測試要測什么，以及如何把它應用在不同的代碼庫當中。

為了更好地了解大家如何檢測漏洞、解決常見安全任務，我們詢問受訪者在過去一年中是否發現過自己的 Go 代碼或依賴項中存在漏洞。對于給出肯定答案的受訪者，我們又進一步提出問題，例如當時是怎么發現漏洞的、如何調查及 / 或解決，以及整個過程中哪些環節最為棘手。

首先，我們發現漏洞掃描確有成效。四分之一的受訪者表示從第三方依賴項中發現了漏洞。但實際使用漏洞掃描的受訪者只占三分之一，所以在這部分群體中再統計依賴項漏洞比例時，我們發現結果從 25% 倍增至 46%。除了依賴項和 Go 自身的漏洞外，有 12% 的受訪者表示發現的是自己代碼中的漏洞。

大多數受訪者（65%）表示，他們發現的漏洞源自安全掃描程序。受訪者最常用的工具是 GitHub 的 dependabot（38%），使用比例高于所有其他漏洞掃描程序的總和（27%）。除掃描之外，受訪者了解漏洞的其他常見方式還包括公共報告，例如發布說明和 CVE（22%）。

在意識到存在漏洞后，受訪者們最常見的解決方法（67%）是升級相應依賴項。在使用漏洞掃描程序（專門用于檢測第三方依賴項中漏洞）的受訪者中，選擇升級依賴項的比例則上升至 85%。近三分之一的受訪者會閱讀 CVE 或漏洞報告（31%），只有 12% 的受訪者會進一步做深入調查，了解自己的軟件是否受到影響、受到怎樣的影響。

只有 12% 的受訪者表示會對代碼漏洞造成的潛在影響做進一步調查，這樣的比例確實低得令人吃驚。為了掌握更多細節，我們還詢問受訪者在應對漏洞方面遇到過哪些挑戰。幾個主要答案的占比基本相當，包括害怕依賴項更新會影響代碼執行，以及通過 go.mod 文件更新間接依賴項的難度較高等。

我們也詢問了一般使用哪種調查方式了解漏洞影響或探究根本原因，這 12% 愿意做進一步調查的受訪者們給出了更積極的答案：其中 70% 對漏洞的潛在影響進行了調查，并發現這才是整個過程中最困難的部分。

除了調查本身的難度，他們還提到這項工作通常不在項目計劃之內，而且完全沒有直接回報。

Go 團隊認為，這種深入調查應用程序中各依賴項安全態勢的好習慣，將直接決定漏洞可能給組織帶來的實際風險、甚至是否發生數據泄露。

因此，我們設計出 govulncheck，在調用的函數中存在漏洞時向開發者發出提醒，并列出該函數在代碼中的確切位置。希望這款工具能幫助開發者快速對應用程序中的致命漏洞進行調查，減少計劃外的安全工作負擔。

工具體驗

下面，我們又詢問了關于工具體驗的問題：

自上次調查以來，編輯環境是否發生了變化？

開發者愿意使用工作區嗎？如果愿意，在初上手時感覺有哪些不便？

開發者如何處理內部包文檔？

VS Code 在受訪者中的人氣似乎還在持續增長。自 2021 年以來，受訪者就將其選為最受歡迎的 GO 代碼編輯器，今年的支持比例更是從 42% 上升至 45%。VS Code 和 GoLand 兩大高人氣編輯器似乎不受組織規模的影響，在大企業和小公司里都很受歡迎。但從統計結果來看，業余開發者似乎更偏愛 VS Code。

在 2021 年通過 gopls 語言服務器強化 VS Code 的 Go 支持能力之后，Go 團隊一直想了解 gopls 中存在哪些使用痛點。雖然我們已經從開發者那邊收到了不少反饋，但不清楚會不會有很多開發者直接禁用掉了這項功能。

為了收集關于 gopls 的負面意見，我們專門統計了那些所使用的編輯器能夠支持 gopls 的受訪者（無論他們是否實際使用 gopls），并發現禁用比例只有 2%。而且在 VS Code 上，禁用比例更是下降至 1%。這讓我們對 gopls 的表現更具信心，也期待大家在 GitHub 上提交更多關于 gopls 的問題。

在工作區這邊，很多受訪者似乎是在本次調查中才知道 Go 能夠支持多模塊工作區。對 VS Code 用戶的隨機調查顯示，大多數受訪者從來就沒聽說過工作區（在隨機抽樣受訪者中占比 53%，在自薦受訪者中占比 33%）。

其實對泛型的認知和接納差異在這兩個受訪者群體間也體現得非常明顯，分別為 93% 和 68%。也許是因為我們目前的 Go 博客或社交媒體渠道還不足以涵蓋足夠的 Go 開發者，所以很多新功能并不能有效傳遞至用戶耳中。

我們還發現，有 9% 的受訪者曾經試用過工作區，另有 5% 表示想要嘗試但最終未能進行。關于使用 Go 工作區的阻礙，位居榜首的是 go work 命令缺乏說明文檔和有意義的錯誤消息（21%），其次則是要求重構現有 repo（13%）。

與安全部分的討論類似，同樣有不少受訪者給出了“沒時間 / 不是優先事項”之類的理由。按照我們的理解，這意味著跟實際帶來的收益相比，工作區的理解和設置門檻仍然偏高，也可能是開發者之前就已經找到了自己的解決辦法。

在 Go 模塊發布之前，不少組織已經在通過內部文檔服務器（例如支持 godoc.org 的服務器）為員工提供內部 Go 包文檔。但現在，這類服務器的設置流程比以往更為復雜，我們也在考慮要不要投資來簡化這個過程。因此，我們詢問受訪者如何查看內部 Go 模塊文檔，想了解這是不是他們的首選工作方式。

結果顯示，目前最常見的內部 Go 文檔查看方式是閱讀代碼（81%），其中約半數覺得這樣就挺好，但也有 39% 認為能有內部文檔服務器就更好了。

我們還詢問了這類服務器應該由誰配置和維護，有三分之二的受訪者認為應該是軟件工程師，余下三分之一覺得可以指派專門的 IT 支持或運營人員。

從這個角度看，理想的文檔服務器應該是那種交鑰匙解決方案，或者至少不會帶來過多的額外工作負擔（一個人在午休時間就能維護好）。考慮到目前開發人才嚴重短缺的現實，這樣的要求完全在情理之中。

調查對象

總體而言，自 2021 年的調查以來，受訪者群體的基本特征并沒有太大變化。部分受訪者（53%）擁有兩年及以上 Go 使用經驗，其余受訪者則是 Go 社區中的新人。

約三分之一受訪者來自小型企業（員工少于 100 人），四分之一來自中型企業（100 至 1000 名員工），四分之一來自大型企業（員工超過 1000 人）。與去年類似，我們發現 VS Code 上的調查彈窗吸引到了不少北美和歐洲以外地區的開發者。

受訪者們如何使用 Go 語言

受訪者使用 Go 語言的具體方式跟上年相比，同樣沒有出現什么統計意義上的差異。最常見的兩大用例仍然是構建 API/RPC 服務（73%）和編寫 CLI（60%）。

我們使用線性模型，嘗試調查受訪者使用 Go 的時間與他們的開發方向之間是否存在關聯。我們發現，Go 經驗不足一年的受訪者一般更關注 GUI、物聯網、游戲、機器學習 /AI 或移動應用等開發目標。而一年以上受訪者則明顯較少用 Go 語言進行這些領域的開發，說明他們可能是在實踐當中遇到了重大障礙。

大多數受訪者會在 Linux（59%）或 macOS（52%）上進行 Go 開發，而部署目的地則絕大多數是 Linux 系統（93%）。在本次調查中，我們新增了在 Windows Subsystem for Linux（WSL）上進行 Go 開發的選項，并發現有 13% 的受訪者選擇了這種方式。

感受與挑戰

最后，我們詢問了受訪者過去一年來對 Go 的總體使用感受，特別是使用 Go 時遇到過的最大挑戰。我們發現，93% 的受訪者表示“還行”（30%）或非常滿意（63%），基本與 2021 年調查得到的 92% 持平。

多年以來，泛型一直是 Go 開發中的爭議焦點。Go 1.18 對類型參數的支持雖然緩和了舊矛盾，但又帶來了錯誤處理這個新問題。可以肯定的是，錯誤處理不是孤立存在的，與庫缺失或不夠成熟、開發者學習難度大、最佳實踐不易實施、對類型系統的其他修訂（例如支持枚舉及更多函數式編程語法）等其他問題密切相關。總之，除了泛型之外，Go 開發者還需要面對坎坷的前進道路。

總結

本次 Go 開發者調查主要側重于 Go 1.18 版本中的新功能。我們發現泛型的普及正在穩步推進，但開發者也遇到了當前實現中的不少限制。模糊測試和工作區的普及率仍然有限，但核心并非技術原因：要想擴大受眾，這兩項功能首先需要解決什么時候用、怎么用的問題。

另一個阻礙則是開發者沒工夫關注這些新特性，這一點在安全開發方面也有體現。根據這些結論，Go 團隊將確定下一步工作的優先級，并影響到未來的工具設計思路。