Go 官方通过 gofmt 强制统一代码风格，其中内联注释（即与代码同行的 // 注释）应保持紧凑对齐，但更推荐将参数说明写入函数文档，变量/语句注释则优先使用独立注释行。
go 官方通过 `gofmt` 强制统一代码风格，其中内联注释（即与代码同行的 `//` 注释）应保持紧凑对齐，但更推荐将参数说明写入函数文档，变量/语句注释则优先使用独立注释行。
在 Go 生态中，gofmt 不仅是工具，更是编码规范本身——它不提供配置项，其输出即为唯一被接受的格式标准。你观察到的“注释被压缩或拉伸”现象，并非 bug，也非随意行为，而是 gofmt 对内联注释位置与对齐逻辑的确定性处理结果：
- gofmt 会将函数参数列表中的 // 注释统一右移到参数声明行末，并保留单空格分隔，同时尽可能压缩横向空白（如移除参数间的多余空格），使注释紧贴代码右侧；
- 对于函数体内的语句，gofmt 同样将内联注释右对齐至统一列（默认约在第80列附近），但实际对齐位置取决于该行代码长度：较短语句的注释会被“拉远”，较长语句则“挤近”，从而形成视觉上不一致的间距——这正是你示例中 start := true 后注释显得“被扩展”的原因。
然而，Go 社区普遍认为：内联注释不是首选表达方式。官方标准做法是：
✅ 函数/方法参数说明 → 写入顶部文档注释（// 块）
参考 math/big.Int.Exp 的典范写法：
// Exp sets z = x**y mod |m| (i.e. the sign of m is ignored), and returns z.
// If y <= 0, the result is 1 mod |m|; if m == nil or m == 0, z = x**y.
// See Knuth, volume 2, section 4.6.3.
func (z *Int) Exp(x, y, m *Int) *Int { ... }此处 x, y, m 的语义、约束与交互逻辑均在文档中清晰定义，无需在签名中重复注释。
✅ 局部变量或关键语句说明 → 使用独立注释行（preceding comment）
更清晰、更易维护，且完全兼容 gofmt：
// First-number switch.
start := true
// Output channel, this instance.
ouch := make(chan int)
// Print this instance's prime.
fmt.Printf("%v ", mine)gofmt 会保留空行和注释位置，且此类写法在 godoc 渲染、静态分析（如 staticcheck）及 IDE 支持中表现更优。
⚠️ 注意事项：
- 避免混合使用内联注释与独立注释描述同一逻辑，易造成冗余或不一致；
- gofmt 不处理注释内容质量，但 golint（已归并至 revive 等现代工具）会提示“comment on exported function should be of the form ‘FuncName …’”，强调文档注释的规范性；
- 若必须使用内联注释（如调试标记 // TODO: optimize 或极简上下文提示），应确保其简短、必要，且不破坏可读性。
总结：gofmt 的注释对齐是确定性算法的结果，但真正的 Go 风格在于用文档注释阐明接口契约，用前置注释解释执行意图——代码自解释，注释作补充，而非补丁。
