标签 C 下的文章

Go项目设计的“七宗罪”?警惕那些流行的“反模式”

本文永久链接 – https://tonybai.com/2025/04/21/go-project-design-antipatterns

大家好,我是Tony Bai。

在软件开发这个行当里,“最佳实践”、“设计模式”、“标准规范”这些词汇总是自带光环。它们总是承诺会带来更好的代码质量、可维护性和扩展性。然而,当这些“圣经”般的原则被生搬硬套到Go语言的语境下时,有时非但不能带来预期的好处,反而可能把我们引入“歧途”,滋生出一些看似“专业”实则有害的“反模式”。

最近我也拜读了几篇国外开发者关于Go项目布局和设计哲学的文章,结合我自己这些年的实践和观察,我愈发觉得,Go社区中确实存在一些需要警惕的、流行的设计“反模式”。这些“反模式”很多人都或多或少的使用过,包括曾经的我自己。

在这篇文章中,我就总结一下我眼中的Go项目设计“七宗罪”,希望能帮助大家在实践中保持清醒,做出更符合Go精神的决策。

第一宗罪:为了结构而结构——过度分层与分组

表现: 项目伊始,不假思索地创建pkg/、internal/、cmd/、util/、model/、handler/、service/ 等层层嵌套的目录,美其名曰“组织清晰”、“符合标准”。

危害:
* 违背简洁: Go 的核心哲学是简洁。不必要的目录层级增加了认知负担和导航成本。
* 过早抽象/耦合: 在需求尚不明确时就划分 service、handler 等,可能导致错误的抽象边界和不必要的耦合。
* pkg/ 的迷思: pkg/ 是一个过时的、缺乏语义的约定,Go官方在Go 1.4时将Go项目中的pkg层次去掉了,Go官方的module布局指南中也使用了更多有意义的名字代替了pkg。
* internal/ 的滥用: 它是 Go 工具链的一个特性,用于保护内部实现不被外部导入。但如果你的项目根本不作为库被外部依赖,或者需要保护的代码很少,强制使用 internal/ 只会徒增复杂性。
* cmd/ 的误用: 除非你的仓库包含多个独立的可执行文件,否则将单一的main.go放入cmd/毫无必要。

解药: 保持扁平!从根目录开始,根据实际的功能或领域需要创建有意义的包。让结构随着项目的增长有机演化,而不是一开始就套用模板。

注:笔者当年也是pkg的“忠实粉丝”,新创建一个项目,无论规模大小,总喜欢先将pkg目录预创建出来。现在是时候根据项目的演进和规模的增长来判断是否需要”pkg”这个有点像“namespace”的目录了,即当你有多个希望公开的库时,是否用pkg/作为一个顶层分组,这个是要基于项目的实际情况进行判断的。

第二宗罪:无效的“美化运动”——无价值的重构与移动

表现: 为了让代码看起来“更干净”、“更符合某种设计模式”或“消除Linter警告”,在没有明确收益(修复 Bug、增加功能、提升性能、解决安全问题)的情况下,大规模地移动代码、修改变量名、调整文件结构。

危害:
* 浪费时间精力: 投入大量时间做无意义的表面文章。
* 引入风险: 任何修改都有引入新 Bug 的风险,没有价值的修改更是得不偿失。
* 增加 Code Review 负担: 团队成员需要花费时间理解这些非功能性的变更。
* 违背价值驱动: 软件工程的核心是交付价值,而不是追求代码的“艺术感”。

解药: 坚持价值驱动的变更!在做任何结构或代码调整前,严格拷问自己:这个改动解决了什么真实的、当前存在的问题?它的收益是否能明确衡量并大于风险?

第三宗罪:接口的“原罪”——过早、过度的抽象

表现:
* 在只有一个具体实现的情况下,就为其定义接口。
* 定义庞大、臃肿的接口,包含过多方法。
* 为了“可测试性”而无脑地给所有东西加上接口。

危害:
* 不必要的抽象: 接口是为了解耦和多态。在不需要这些时引入接口,只会增加代码量和理解成本。
* 弱化抽象能力: “接口越大,抽象越弱”(来自Go谚语)。大接口难以实现和维护,它变得模糊,难以理解哪些方法是真正必要的,也失去了其作为“契约”的精准性。
* 阻碍演化: 过早定义接口可能锁定不成熟的设计,后续修改成本更高。
* 测试的借口: Go拥有强大的测试工具(如表驱动测试),很多时候并不需要接口来实现可测试性。为测试而引入的接口可能扭曲生产代码的设计。

解药:
* 拥抱具体: 先写具体实现。
* 发现接口,而非设计接口: 只有当你确实需要多种实现(包括测试中的Mock,但要谨慎对待),或者需要打破循环依赖时,才考虑提取接口。
* 保持接口小巧、正交: 遵循接口隔离原则。

第四宗罪:“大杂烩”的诱惑——utils/common/shared 黑洞

表现: 创建一个名为 utils、common、shared 或 helpers 的包,把各种看似“通用”的函数、类型塞进去。

危害:
* 职责不清: 这些包缺乏明确的领域或功能归属,成为代码的“垃圾抽屉”。
* 依赖洼地: 随着项目增长,这些包往往会依赖越来越多的其他包,同时也被越来越多的包依赖,极易引发循环依赖或成为构建瓶颈。
* 降低内聚性: 本应属于特定领域的功能被剥离出来,破坏了原有包的内聚性。

解药:
* 就近原则: 如果一个“工具函数”只被一个包使用,就把它放在那个包里(可以是私有的)。
* 功能归类: 如果一个“工具函数”被多个包使用,思考它真正属于哪个功能领域,为其创建一个有意义的新包(例如 applog 而不是 logutil)。
* 思考依赖方向: 真正通用的基础库(如自定义的 string 处理、时间处理)应该处于依赖关系图的底层,不应依赖上层业务逻辑。

注:坦白说,其他几项“罪过”或许还只是部分开发者的“偶发行为”,但这“第四宗罪”——随手创建 utils 或 common 包——恐怕是我们绝大多数人都曾犯过,甚至习以为常的“通病”。笔者也是如此:)。

第五宗罪:对 DRY 的“迷信”——为了“不重复”而引入不当依赖

表现: 为了避免几行相似代码的重复,强行提取公共函数或类型,并为此引入新的包依赖,有时甚至导致复杂的依赖关系或循环依赖。

危害:
* 错误的抽象: 有时看似重复的代码,在不同的上下文中可能有细微的差别或独立演化的需求。强行合并可能导致错误的抽象。
* 不必要的耦合: 为了共享几行代码而引入整个包的依赖,增加了耦合度,可能比少量重复代码的维护成本更高。
* 违背 Go 谚语: “A little copying is better than a little dependency.”(一点复制代码胜过一点点依赖)。Go 社区鼓励在权衡后接受适度的代码重复,以换取更低的耦合度和更高的独立性。

解药:
* 批判性看待重复: 看到重复代码时,先思考它们是否真的是“同一件事”?它们的演化趋势是否一致?
* 权衡成本: 引入依赖的成本(耦合、潜在冲突、维护负担)是否真的低于复制代码的成本?
* 优先考虑简单: 在不确定时,保持简单,适度复制代码通常更安全。

注:这种事儿,恐怕咱们自己或者团队里都遇到过不少:就为了用里面那一两个小函数,咔嚓一下,引入了一个庞大无比的依赖库。

第六宗罪:盲目崇拜与跟风——“伪标准”与“最佳实践”的陷阱

表现:
* 不加批判地复制某个“明星项目”或所谓的“Go 标准项目布局”(如已被社区诟病的golang-standards/project-layout)。
* 将其他语言(如 Java, C#)的复杂模式生搬硬套到 Go 项目中。
* 将任何 Linter 规则或所谓的“最佳实践”奉为圭臬,不考虑具体场景。

危害:
* 脱离实际: 别人的“最佳实践”是基于他们的特定问题和上下文演化而来的,未必适合你的项目。
* 扼杀思考: 放弃了基于自己项目需求进行独立思考和决策的机会。
* 违背Go文化: Go 推崇实用主义和具体问题具体分析,而非僵化的教条。

解药:
* 保持独立思考: 理解每个模式或实践要解决的原始问题是什么,它是否在你的项目中真实存在?
* 以我为主,兼收并蓄: 学习和借鉴,但最终决策要基于你自己的项目需求、团队情况和对 Go 语言的理解。
* 质疑“最佳”: 没有万能的“最佳实践”,只有在特定上下文中的“较好实践”。

注:确实,很多Go初学者(甚至一些老手,包括我自己)都曾长期困惑甚至“抱怨”:官方为何不给出一个项目布局的指导呢?这个呼声持续多年后,Go官方终于在2023年发布了一份官方布局指南。这份指南无疑是我们理解官方思路、开始设计Go项目布局的一个重要起点。

第七宗罪:与“引力”对抗——忽视 Go 的依赖约束

表现:
* 设计出隐含循环依赖的架构(例如,某些复杂的 ORM 模式,或者 Service 层与 Repository 层相互调用具体类型)。
* 当遇到 import cycle not allowed 错误时,不从根本上调整结构,而是通过滥用接口、全局变量或 init() 函数等“技巧”来绕过编译错误。

危害:
* 与语言对抗: Go禁止循环依赖是其核心设计之一,旨在强制形成清晰的、可管理的依赖关系图 (DAG)。试图绕过它,本质上是在与语言的设计哲学对抗。
* 隐藏的复杂性: 用“技巧”解决循环依赖,只是将问题扫到地毯下,使得真实的依赖关系变得模糊不清,增加了维护难度。
* 错失优化机会: 循环依赖往往是代码职责不清、耦合过度的信号。解决循环依赖的过程,本身就是一次优化架构、厘清职责的好机会。

解药:
* 拥抱 DAG: 理解并尊重 Go 的依赖规则,将其视为架构设计的“向导”。
* 分析依赖: 当出现循环依赖时,深入分析其根源,理解是哪个环节的职责划分或耦合出了问题。
* 结构性解决: 优先使用移动代码、提取新包(向上或向下)等结构性方法来打破循环。接口解耦是可用手段,但不应是首选或唯一手段。

小结:回归常识,拥抱简洁

Go语言的设计哲学是务实和简洁。许多所谓的“最佳实践”和“复杂模式”,在Go的世界里可能水土不服。识别并避免上述这些“反模式”,需要我们:

  • 保持批判性思维: 不盲从,不跟风,时刻追问“为什么”。
  • 坚持价值驱动: 让每一个设计决策都服务于解决真实问题。
  • 深刻理解Go: 尊重其核心约束(如无循环依赖),发挥其优势(如简洁性)。
  • 拥抱演化: 从简单开始,让架构随着需求的明确而有机生长。

希望这篇“七宗罪”的总结能给大家带来一些警示和启发。你是否也曾在项目中遇到过这些“反模式”?你认为还有哪些Go设计中需要警惕的“坑”?欢迎在评论区分享你的看法和经验!

也别忘了点个【赞】和【在看】,让更多Gopher看到这篇“反模式”的总结!


避开这些设计“反模式”是迈向Go高手的关键一步。如果你渴望更深层次地理解Go语言精髓,与顶尖Gopher交流切磋,并紧跟Go+AI前沿动态…

那么,我的 「Go & AI 精进营」知识星球 正是你需要的!在这里,你可以沉浸式学习【Go原理/进阶/避坑】等独家深度专栏,随时向我提问获
得解析,并与高活跃社区成员碰撞思想火花。

扫码加入,开启你的Go深度学习与精进之旅!

img{512x368}

11个现代Go特性:用gopls/modernize让你的代码焕然一新

本文永久链接 – https://tonybai.com/2025/04/15/embrace-modern-go-style-with-gopls-modernize

大家好,我是Tony Bai。

最近在思考Go语言的发展时,不禁让我想起了当年学习C++的经历。Bjarne Stroustrup在《C++程序设计语言(特别版)》中就专门强调了“现代 C++”(Modern C++)的编程风格,鼓励使用模板、STL等新特性来编写更优雅、更高效的C++代码。

那么,我们热爱的Go语言,随着版本的不断迭代,是否也逐渐形成了一种“现代Go”(Modern Go)的风格呢?答案是肯定的。Go团队不仅在语言层面引入新特性(如泛型range over int),也在标准库中添加了更强大、更便捷的包(如slices、maps)。

更棒的是,Go官方工具链gopls(Go Language Server Protocol的实现)中,就内置了一个名为modernize的分析器(Analyzer),专门用于帮助我们识别代码中可以用现代Go风格替代的“旧习”,并给出建议。

今天,我们就来深入了解一下gopls/modernize这个利器,看看它如何帮助我们的Go代码焕然一新,并学习一下它所倡导的11个“现代Go”风格语法要素具体包含哪些内容。

1. gopls/modernize分析器以及现代Go风格简介

gopls/modernize是golang.org/x/tools/gopls/internal/analysis/modernize 包提供的一个分析器。它的核心目标就是扫描你的Go代码,找出那些可以通过使用Go 1.18及之后版本引入的新特性或标准库函数来简化的代码片段。

modernize工具目前可以识别并建议修改多种“旧”代码模式。让我们逐一看看这些建议,并附上代码示例:

(注:以下示例中的版本号指明了该现代写法是何时被推荐或可用的)

1). 使用min/max内建函数 (Go 1.21+)

  • 旧风格: 使用 if/else 进行条件赋值来找最大/最小值。
func findMax(a, b int) int {
    var maxVal int
    if a > b {
        maxVal = a
    } else {
        maxVal = b
    }
    return maxVal
}
  • 现代风格: 直接调用 max 内建函数。
import "cmp" // Go 1.21 implicitly uses built-ins, Go 1.22+ might suggest cmp.Or for clarity if needed

func findMaxModern(a, b int) int {
    // Go 1.21 onwards have built-in min/max
    return max(a, b)
    // Note: for floats or custom types, use cmp.Compare from "cmp" package
}
  • 理由: 更简洁,意图更明确。

2). 使用slices.Sort (Go 1.21+)

  • 旧风格: 使用 sort.Slice 配合自定义比较函数对 slice 排序。
import "sort"

func sortInts(s []int) {
    sort.Slice(s, func(i, j int) bool {
        return s[i] < s[j] // Common case for ascending order
    })
}
  • 现代风格: 使用 slices.Sort 或 slices.SortFunc / slices.SortStableFunc。
import "slices"

func sortIntsModern(s []int) {
    slices.Sort(s) // For basic ordered types
}

// For custom comparison logic:
// func sortStructsModern(items []MyStruct) {
//     slices.SortFunc(items, func(a, b MyStruct) int {
//         return cmp.Compare(a.Field, b.Field) // Using cmp.Compare (Go 1.21+)
//     })
// }
  • 理由: slices包提供了更丰富、类型更安全的排序功能,且通常性能更好。

3). 使用 any 替代 interface{} (Go 1.18+)

  • 旧风格: 使用 interface{} 表示任意类型。
func processAnything(v interface{}) {
    // ... process v ...
}
  • 现代风格: 使用 any 类型别名。
func processAnythingModern(v any) {
    // ... process v ...
}
  • 理由: any 是 interface{} 的官方别名,更简洁,更能体现其“任意类型”的语义。

4). 使用 slices.Clone 或 slices.Concat (Go 1.21+)

  • 旧风格: 使用 append([]T(nil), s…) 来克隆 slice。
func cloneSlice(s []byte) []byte {
    return append([]byte(nil), s...)
}
  • 现代风格: 使用 slices.Clone。
import "slices"

func cloneSliceModern(s []byte) []byte {
    return slices.Clone(s)
}
  • 理由: slices.Clone 意图更明确,由标准库实现可能更优化。slices.Concat 则用于拼接多个 slice。

5). 使用 maps 包函数 (Go 1.21+)

  • 旧风格: 手动写循环来拷贝或操作 map。
func copyMap(src map[string]int) map[string]int {
    dst := make(map[string]int, len(src))
    for k, v := range src {
        dst[k] = v
    }
    return dst
}
  • 现代风格: 使用 maps.Clone 或 maps.Copy。
import "maps"

func copyMapModern(src map[string]int) map[string]int {
    return maps.Clone(src) // Clone creates a new map
}

func copyMapToExisting(dst, src map[string]int) {
     maps.Copy(dst, src) // Copy copies key-values, potentially overwriting
}
  • 理由: maps 包提供了标准化的 map 操作,代码更简洁,不易出错。还有 maps.DeleteFunc, maps.Equal 等实用函数。

6). 使用 fmt.Appendf (Go 1.19+)

  • 旧风格: 使用 []byte(fmt.Sprintf(…)) 来获取格式化后的字节 slice。
import "fmt"

func formatToBytes(id int, name string) []byte {
    s := fmt.Sprintf("ID=%d, Name=%s", id, name)
    return []byte(s)
}
  • 现代风格: 使用 fmt.Appendf,通常配合 nil 作为初始 slice。
import "fmt"

func formatToBytesModern(id int, name string) []byte {
    // Appends formatted string directly to a byte slice
    return fmt.Appendf(nil, "ID=%d, Name=%s", id, name)
}
  • 理由: fmt.Appendf 更高效,它避免了先生成 string 再转换成 []byte 的中间步骤和内存分配。

7). 在测试中使用 t.Context (Go 1.24+)

  • 旧风格: 在测试函数中需要 cancellable context 时,使用 context.WithCancel。
import (
    "context"
    "testing"
    "time"
)

func TestSomethingWithContext(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    // Use ctx in goroutines or functions that need cancellation
    go func(ctx context.Context) {
        select {
        case <-time.After(1 * time.Second):
            t.Log("Worker finished")
        case <-ctx.Done():
            t.Log("Worker cancelled")
        }
    }(ctx)

    // Simulate test work
    time.Sleep(100 * time.Millisecond)
    // Maybe cancel based on some condition, or rely on defer cancel() at end
}
  • 现代风格: 直接使用 testing.T 提供的 Context() 方法。
import (
    "context"
    "testing"
    "time"
)

func TestSomethingWithContextModern(t *testing.T) {
    // t.Context() is automatically cancelled when the test (or subtest) finishes.
    // It may also be cancelled sooner if the test times out (e.g., using t.Deadline()).
    ctx := t.Context()

    go func(ctx context.Context) {
        select {
        case <-time.After(1 * time.Second):
            t.Log("Worker finished")
        case <-ctx.Done():
            t.Logf("Worker cancelled: %v", ctx.Err()) // Good practice to log the error
        }
    }(ctx)

    time.Sleep(100 * time.Millisecond)
}
  • 理由: t.Context() 更方便,自动管理 context 的生命周期与测试的生命周期绑定,减少了样板代码,并能正确处理测试超时。

8). 使用 omitzero 代替 omitempty (Go 1.24+)

  • 旧风格: 在 json 或类似 tag 中使用 omitempty,它会在字段值为其类型的零值(如 0, “”, nil, 空 slice/map)时省略该字段。但对于空结构体字段则表现不如预期:
type ConfigOld struct {
    EmptyStruct struct{} `json:",omitempty"`
}

// JSON 输出为 {"EmptyStruct":{}}
  • 现代风格: 如果意图是“当字段值为零值时省略”,则使用 omitzero。
type ConfigModern struct {
    EmptyStruct struct{} `json:",omitzero"`
}
// JSON 输出为 {}

9). 使用 slices.Delete (Go 1.21+)

  • 旧风格: 使用 append(s[:i], s[i+1]…) 来删除 slice 中的单个元素。
func deleteElement(s []int, i int) []int {
    if i < 0 || i >= len(s) {
        return s // Index out of bounds
    }
    return append(s[:i], s[i+1:]...)
}
  • 现代风格: 使用 slices.Delete 删除一个或一段元素。
import "slices"

func deleteElementModern(s []int, i int) []int {
    if i < 0 || i >= len(s) {
        return s
    }
    // Delete element at index i
    return slices.Delete(s, i, i+1)
}

func deleteElementsModern(s []int, start, end int) []int {
     // Delete elements from index start (inclusive) to end (exclusive)
     return slices.Delete(s, start, end)
}
  • 理由: slices.Delete 意图更明确,更通用(可以删除区间),由标准库实现可能更健壮(处理边界情况)。

10). 使用for range n (Go 1.22+)

  • 旧风格: 使用经典的三段式 for 循环遍历 0 到 n-1。
func iterateN(n int) {
    for i := 0; i < n; i++ {
        // Use i
        _ = i
    }
}
  • 现代风格: 使用 for range 遍历整数。
func iterateNModern(n int) {
    for i := range n { // Requires Go 1.22+
        // Use i
         _ = i
    }
}
  • 理由: 语法更简洁。在某些情况下(虽然不常见),如果循环体没有使用 i,for range n 可能比 for i:=0; i<n; i++ 有微弱的性能优势(避免迭代变量的开销)。

11). 使用 strings.SplitSeq (Go 1.24+)

  • 旧风格: 在循环中迭代 strings.Split 的结果。
import "strings"

func processSplits(s, sep string) {
    parts := strings.Split(s, sep)
    for _, part := range parts {
        // Process part
        _ = part
    }
}
  • 现代风格: 如果只是为了迭代,推荐使用 strings.SplitSeq(如果 Go 版本支持)。
import "strings"

func processSplitsModern(s, sep string) {
    // SplitSeq returns an iterator, potentially more efficient
    // as it doesn't necessarily allocate the slice for all parts at once.
    for part := range strings.SplitSeq(s, sep) { // Requires Go 1.24+
        // Process part
         _ = part
    }
}
  • 理由: strings.SplitSeq 返回一个迭代器 (iter.Seq[string]),它在迭代时才切分字符串,避免了一次性分配存储所有子串的 slice 的开销,对于大字符串和/或大量子串的情况,内存效率更高。

2. 为什么要拥抱“现代Go”风格?

通过前面modernize工具支持的现代风格的示例,我们大致可以得到三点采用现代Go风格的好处:

  • 代码更简洁、可读性更高: 新的语言特性或标准库函数往往能用更少的代码、更清晰地表达意图。
  • 利用标准库优化: slices、maps等新包通常经过精心设计和优化,性能和健壮性可能优于手写的等效逻辑。
  • 与时俱进,降低维护成本: 使用社区和官方推荐的新方式,有助于保持代码库的技术先进性,也便于团队成员(尤其是新人)理解和维护。

认识到拥抱“现代 Go”风格的诸多好处,自然会问:如何使用modern工具才能帮助我们识别并实践这些风格呢?接下来我们就来看看modernize工具的用法。

3. 如何在你的项目中使用 modernize

modernize工具本身是一个命令行程序。你可以通过以下方式在你的项目根目录下运行它:

$go run golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest [flags] [package pattern]
  • [package pattern]:指定要扫描的包,通常我们会使用 ./… 来扫描当前目录及其所有子目录下的包。
  • [flags]:一些常用的标志:
    • -test (boolean, default true):是否分析测试文件 (_test.go)。默认是分析的。
    • -fix (boolean, default false):自动应用所有建议的修复。请谨慎使用,建议先人工检查或在版本控制下使用。
    • -diff (boolean, default false):如果同时使用了 -fix,此标志会让工具不直接修改文件,而是打印出 unified diff 格式的变更内容,方便预览。

执行示例:

正如我在我的两个开源项目go-cache-proglocal-gitingest中尝试的那样:

➜  /Users/tonybai/go/src/github.com/bigwhite/go-cache-prog git:(main) $ go run golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest -test ./...
/Users/tonybai/go/src/github.com/bigwhite/go-cache-prog/cmd/go-cache-prog/main.go:19:2: Loop can be simplified using slices.Contains
exit status 3

➜  /Users/tonybai/go/src/github.com/bigwhite/local-gitingest git:(main) ✗ $ go run golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest -test ./...
/Users/tonybai/go/src/github.com/bigwhite/local-gitingest/main_test.go:191:5: Loop can be simplified using slices.Contains
exit status 3

我们看到modernize的输出格式为:

文件路径:行号:列号: 建议信息。

这里的 exit status 3 通常表示 Linter 发现了问题。它提示我在这两个项目的指定位置,存在一个循环可以用 slices.Contains 来简化(这也是 modernize 支持的一个检查,虽然未在上述重点说明的现代风格列表中,但也属于简化代码的范畴)。

注意: 工具的文档提到,如果修复之间存在冲突(比如一个修复改变了代码结构,使得另一个修复不再适用或需要调整),你可能需要运行 -fix 多次,直到没有新的修复被应用。

IDE 集成:

好消息是,如果你在使用 VS Code、GoLand 等配置了 gopls 的现代 Go IDE,很多 modernize 提出的建议通常会直接以代码高亮或建议(Quick Fix / Intention Action)的形式出现在你的编辑器中,让你可以在编码时就实时地进行现代化改造。

掌握了如何在项目中使用 modernize 工具后,让我们回到最初的话题,对这个工具及其倡导的“现代 Go”风格做一些思考和总结。

4. 小结

gopls/modernize不仅仅是一个代码检查工具,它更像是Go语言演进过程中的一个向导,温和地提醒我们:“嘿,这里有更现代、可能更好的写法了!”

拥抱“现代 Go”风格,利用好 modernize 这样的工具,不仅能让我们的代码库保持活力,也能促使我们不断学习和掌握 Go 的新知识。这与当年拥抱“现代 C++”的精神是一脉相承的。

建议大家不妨在自己的项目上运行一下 modernize 工具,看看它能给你带来哪些惊喜和改进建议。也欢迎在评论区分享你使用 modernize 的经验或对“现代 Go”风格的看法!觉得这篇文章有用?点个‘在看’,分享给更多Gopher吧!

免责声明: modernize 工具及其命令行接口 golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize 目前并非官方稳定支持的接口,未来可能会有变动。使用 -fix 功能前请务必备份或确保代码已提交到版本控制系统。


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}
img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格6$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats