Go 官方通过 gofmt 强制统一代码风格，其中内联注释（即写在代码行末的 // 注释）的排版遵循“对齐至统一缩进列”的规则，而非自由换行或语义分组；但更推荐将参数说明移至函数文档注释，变量/语句注释则应独立成行。
go 官方通过 `gofmt` 强制统一代码风格，其中内联注释（即写在代码行末的 `//` 注释）的排版遵循“对齐至统一缩进列”的规则，而非自由换行或语义分组；但更推荐将参数说明移至函数文档注释，变量/语句注释则应独立成行。
在 Go 中，gofmt 并非简单“压缩”或“展开”注释，而是严格依据列对齐策略重排内联注释：它会将所有同一逻辑块（如函数签名、同级语句）中的 // 注释统一右对齐到一个预设的列位置（通常为第40–50列，取决于上下文宽度），以保证视觉一致性。例如：
func sieve(mine int, // This instance's own prime
inch chan int, // Input channel from lower primes
done chan int, // Channel for signalling shutdown
count int) { // Number of primes - counter
start := true // First-number switch
ouch := make(chan int) // Output channel, this instance
fmt.Printf("%v ", mine) // Print this instance's prime
}你观察到的“压缩”现象，实则是 gofmt 将原本错落的注释位置统一拉齐——它不关心语义是否紧凑，只确保注释起始列对齐，从而提升扫描可读性（尤其在长参数列表中）。但这恰恰揭示了一个更重要的工程共识：Go 社区并不鼓励过度依赖行末注释来解释接口含义。
✅ 正确做法是：
- 函数/方法参数说明应写在 // 文档注释块中（即 godoc 可解析的顶部注释），清晰描述每个参数的作用、约束及协作关系。例如：
// sieve runs a concurrent prime sieve worker.
// mine is this instance's own prime number (must be > 1).
// inch receives candidate numbers from smaller primes.
// done signals shutdown; the caller must close it when done.
// count tracks how many primes have been found so far.
func sieve(mine int, inch chan int, done chan int, count int) {- 局部变量或单行逻辑注释，若需说明意图，应优先使用独占一行的注释，紧邻其作用对象上方：
// First-number switch: true only for the first value received.
start := true
// Output channel for forwarding candidates to the next prime worker.
ouch := make(chan int)
// Print the prime immediately upon initialization.
fmt.Printf("%v ", mine)⚠️ 注意事项：
- 避免在函数签名中混用内联注释解释参数——这会削弱 godoc 生成质量，且难以维护；
- gofmt 不处理注释内容本身，仅调整位置；若注释文字冗长，应重构为更精炼表述或拆分为多行文档注释；
- 工具链（如 go vet, staticcheck）不会校验注释位置，但团队代码审查应关注注释的存在性、准确性与位置合理性，而非仅依赖 gofmt 的机械对齐。
归根结底，gofmt 是风格执行者，而 Go 的注释约定本质是语义分层：顶层文档注释定义契约，代码内注释聚焦瞬时意图。遵守这一分层，才能写出既符合工具规范、又具备长期可维护性的 Go 代码。
