Always check errors and avoid panic for normal error handling; 2. Use pointers primarily to modify values or avoid copying large structs, knowing slices, maps, and channels are reference types; 3. Pass loop variables as arguments to goroutines to avoid shared variable issues; 4. Prefer slices over arrays and be cautious with shared underlying arrays when slicing; 5. Do not assume map iteration order and sort keys explicitly for ordered output; 6. Coordinate goroutines with sync.WaitGroup or channels to prevent premature program exit; 7. Use defer for reliable cleanup of resources like files and locks; 8. Avoid unnecessary nil checks since nil slices, maps, and channels are safe to range over; 9. Follow Go idioms and standard tools like gofmt, go vet, and consistent naming to write idiomatic, maintainable code.

New Go programmers often come from backgrounds in languages like Python, JavaScript, or Java, and while Go is intentionally simple and readable, there are several common mistakes and misunderstandings that trip up beginners. Here are some of the most frequent pitfalls and how to avoid them.

1. Ignoring or Misusing Error Handling

Go doesn’t have exceptions — instead, errors are returned as values. Newcomers often:

• Ignore returned errors (e.g., file.Write(data) without checking the error).
• Use panic/recover for normal error handling, which is meant for truly exceptional situations.

What to do instead: Always check errors, even if they seem unlikely. Use the standard pattern:

result, err := someFunction()
if err != nil {
    // handle error
    return err
}

And avoid panic unless you're building a library and need to signal a programmer error (like invalid input to a function that shouldn’t accept it).

2. Misunderstanding Pointers and When to Use Them

Go has pointers, but they’re simpler than in C/C . However, beginners often:

• Overuse pointers, thinking they’re always more efficient.
• Get confused about when values are copied vs. when you need a pointer to modify data.

Key points:

• Slices, maps, and channels are reference types — you don’t need to pass them as pointers to modify their contents.
• Structs, on the other hand, are copied by value unless you pass a pointer.
• Use pointers mainly when you want to mutate a value in a function or when dealing with large structs to avoid copying.

Example:

func updatePerson(p *Person) {
    p.Name = "Alice" // modifies the original
}

3. Not Understanding How Goroutines and Closures Interact

One classic gotcha:

for i := 0; i < 5; i   {
    go func() {
        fmt.Println(i)
    }()
}

This often prints 5 five times, not 0 through 4. Why? All goroutines share the same variable i, which has been incremented to 5 by the time they run.

Fix: Pass the loop variable as an argument:

for i := 0; i < 5; i   {
    go func(val int) {
        fmt.Println(val)
    }(i)
}

4. Treating Slices Like Arrays

Go has arrays (fixed-size) and slices (dynamic, built on arrays). Beginners often:

• Declare arrays when they want slices.
• Expect slicing to always create a new underlying array.

Important:

• Slicing a slice shares the same underlying array. Modifying elements can affect the original if you're not careful.
• Use copy() or append() strategically when you need independent data.

Example:

s1 := []int{1, 2, 3}
s2 := s1[1:] // shares underlying array
s2[0] = 99  // s1 is now [1, 99, 3]

5. Forgetting That Map Keys Are Not Ordered

Go randomizes map iteration order for security and consistency. Newcomers often assume maps are ordered by insertion (they’re not).

If you need ordered output, collect the keys, sort them, and iterate:

keys := make([]string, 0, len(m))
for k := range m {
    keys = append(keys, k)
}
sort.Strings(keys)
for _, k := range keys {
    fmt.Println(k, m[k])
}

6. Overusing go Without Coordination

Spawning goroutines without synchronization (using channels or sync.WaitGroup) leads to programs that exit before goroutines finish.

Example of what not to do:

go doSomething()
// program ends — goroutine may not run at all

Fix: Use sync.WaitGroup for simple coordination:

var wg sync.WaitGroup
wg.Add(1)
go func() {
    defer wg.Done()
    doSomething()
}()
wg.Wait()

7. Not Using defer Effectively

defer is powerful for cleanup (closing files, unlocking mutexes), but beginners often forget it or use it inconsistently.

Good pattern:

file, err := os.Open("data.txt")
if err != nil {
    return err
}
defer file.Close() // guaranteed to run when function exits

// use file...

It makes code safer and cleaner.

8. Writing Overly Defensive Code (e.g., Nil Checks Everywhere)

Some new Go devs add nil checks for everything, even when unnecessary.

Remember:

• Slices, maps, and channels can be used even if nil (e.g., iterating over a nil slice works).
• Only check for nil if it indicates a real error state.

Don’t do this unnecessarily:

if mySlice != nil {
    for _, v := range mySlice { ... }
}

Just do:

for _, v := range mySlice { ... } // works fine even if nil

9. Not Embracing Go Idioms and Standard Tools

Go has strong conventions:

• Use gofmt (everyone does — no style debates).
• Follow package and function naming conventions.
• Use go vet and staticcheck to catch bugs.

Don’t fight the tooling — embrace it. The Go community values consistency.

Basically, Go’s simplicity is a strength, but it requires understanding its unique patterns. Avoiding these common mistakes will help you write safer, more idiomatic Go code from the start.

The above is the detailed content of What are some common pitfalls for new Go programmers?. For more information, please follow other related articles on the PHP Chinese website!