Go fix atomictypes 怎样在现代化原子类型（输入边界）

如果项目里还保留着 atomic.AddInt32(&count, 1)、atomic.LoadInt64(&total) 这一类写法，Go 1.27 的 go fix 可以用 atomictypes modernizer 把它们迁移到 atomic.Int32、atomic.Int64 等强类型原子包装器。它解决的不是“把函数名换短”这么简单，而是把变量本身变成只能通过原子方法访问的对象。

这次迁移适合从一个干净分支开始，先看差异，再决定是否应用。下面只讨论输入是原始 sync/atomic 调用、输出是强类型原子变量的场景，不把它扩展成并发模型重构。

最稳妥的做法是先运行 go fix -diff -atomictypes ./...，确认模块的 Go 版本和改动范围，再应用同一个 fixer。迁移完成后，继续使用 Add、Load、Store 等原子方法，不要绕回普通字段读写。

atomictypes 具体会把什么搬到哪里

旧写法把一个普通整数的地址交给原子函数，变量的类型本身并不能阻止其他代码直接读取它。现代写法把存储位置声明为 atomic.Int32，调用点变成接收者方法。这个变化让“原子访问”成为数据类型的一部分，也避免了旧式原子函数在 32 位架构上的对齐隐患。

package counter

import "sync/atomic"

// LegacyCount 保留旧式原子函数的输入形态，便于对照迁移前后。
type LegacyCount struct {
	value int32
}

// ModernCount 让计数值只能通过 atomic.Int32 的方法进行原子访问。
type ModernCount struct {
	value atomic.Int32
}

// Add 使用强类型包装器完成加法，调用方不再传递字段地址。
func (c *ModernCount) Add(delta int32) int32 {
	return c.value.Add(delta)
}

图 1 是这一关系的静态说明图：左侧是“普通整数 + 原始函数”的输入，右侧是“原子包装器 + 方法”的目标。它只帮助理解类型关系，不代表某次命令的实际输出。

先用 diff 看输入边界，再应用 fixer

go fix 默认可以运行多个 modernizer；这次只指定 -atomictypes，便于把审查范围收窄到原子类型迁移。官方建议在干净 Git 状态下操作，因为一次运行可能改动多个文件。

# 只预览 atomictypes，不直接改写工作区。
go fix -diff -atomictypes ./...

# 确认差异后，再在当前模块应用同一个 fixer。
go fix -atomictypes ./...

# 查看当前工具链注册的 fixer，确认命令名称和帮助信息。
go tool fix help atomictypes

这里的输入边界有三层。第一层是工具链：Go 1.27 的 go fix 才把 atomictypes 列为新的 modernizer。第二层是版本语义：现代化器不会为了引入过新的语言或库能力而忽略模块的版本要求。第三层是构造形态：它识别的是原始 sync/atomic 函数调用，不是所有“看起来像计数器”的自定义并发代码。

如果 -diff 没有输出，不要把它理解成工具失效，通常表示当前构建配置下没有匹配项。带有不同 GOOS、GOARCH 或构建标签的文件可能需要在对应配置下单独分析。

迁移后哪些访问方式必须保持原子

迁移后的字段不是普通整数。读取应使用 Load，写入应使用 Store，递增使用 Add，条件更新使用 CompareAndSwap。这能让代码审查更容易发现“某个路径绕过原子访问”的问题。

package counter

import "sync/atomic"

// Gauge 保存可以并发读取的状态值，禁止直接暴露底层整数。
type Gauge struct {
	value atomic.Int64
}

// Set 用 Store 发布新值，调用者不需要接触内部表示。
func (g *Gauge) Set(v int64) {
	g.value.Store(v)
}

// Get 用 Load 读取最近一次完整发布的值。
func (g *Gauge) Get() int64 {
	return g.value.Load()
}

// TrySet 只在当前值仍等于 expected 时更新，失败时保持原值。
func (g *Gauge) TrySet(expected, next int64) bool {
	return g.value.CompareAndSwap(expected, next)
}

不要复制包含原子字段的结构体，也不要把它放进会按值传递的接口或容器设计里。结构体可以由指针持有，并通过小方法封装访问；如果一个旧 API 必须暴露 int64，迁移通常需要在 API 边界显式调用 Load 或 Store，而不是把内部字段直接交出去。

应用改动后的复查顺序

应用 fixer 后，先看 Git diff：确认变量声明、导入和调用点都属于预期范围。再检查是否有外部包依赖旧字段类型、是否有结构体按值返回、是否有生成文件被工具跳过。最后运行项目自己的构建与测试流程；go fix 是源码改写器，不替代业务测试。

如果一次运行中不同 fixer 的改动发生冲突，官方建议再次运行以获得剩余的独立改动，但本主题只聚焦 atomictypes，不要为了追求一次性全量现代化而混入无关 fixer。对于手写的封装、跨包公开字段、特殊构建标签或需要兼容旧 Go 版本的模块，应保留人工决策。

官方资料：https://go.dev/doc/go1.27、https://go.dev/gopls/analyzers、https://go.dev/blog/gofix

常见问题

atomictypes 会把所有整数都改成原子类型吗？

不会。它针对能识别为原始 sync/atomic 调用的代码形态，不是普通整数的通用类型替换器。

为什么要先运行 -diff？

因为 modernizer 会直接改写源码。先看差异可以确认构建配置、字段边界和 API 影响，再决定是否提交。

迁移后可以直接读取 atomic.Int64 的内部值吗？

不应这样做。使用 Load、Store、Add 或 CompareAndSwap 等方法，让访问语义保持原子。