Go 官方通过 gofmt 强制统一代码风格，其中内联注释（即行末注释）需保持右对齐、语义清晰，但更推荐将参数说明写入函数文档，变量/语句注释应独立成行。
go 官方通过 `gofmt` 强制统一代码风格，其中内联注释（即行末注释）需保持右对齐、语义清晰，但更推荐将参数说明写入函数文档，变量/语句注释应独立成行。
在 Go 生态中，“格式即约定”——gofmt 不仅是工具，更是语言规范的一部分。它对内联注释（trailing comments）的处理并非随意压缩或拉伸，而是基于语法节点对齐规则：gofmt 会将同一逻辑组（如函数参数列表、同级变量声明）中的行末注释统一右对齐到一个列宽（通常为 40–60 列，取决于上下文长度），以提升可读性。你观察到的“压缩”与“扩展”，实则是 gofmt 将注释锚定到其所属语法项末尾后，自动补足空格实现视觉对齐的结果。
例如，原始代码中参数名长度不一，gofmt 并未改变注释内容，而是将每行注释统一推至大致相同的列位置：
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注意：gofmt 不会调整注释位置来“适配”人为插入的空格，也不会因注释过长而换行——它只做对齐，不做语义重排。
然而，Go 社区更倡导的注释实践是语义分层：
- ✅ 函数/方法签名参数说明 → 写入 // 开头的顶部文档注释（即 godoc 注释），使用自然语言描述各参数含义及约束；
- ✅ 单行语句意图说明 → 独立成行注释，以句号结尾，清晰表达“做什么”，而非“是什么”；
- ❌ 避免过度依赖行末注释 → 尤其当逻辑复杂或注释较长时，行末注释易破坏代码节奏，且 gofmt 对齐后可能降低可维护性。
正确示例（符合 Go 风格指南）：
// sieve runs a concurrent prime sieve step.
// It receives candidates via inch, prints 'mine' as a prime,
// and forwards filtered numbers to ouch. Shutdown is signaled via done.
func sieve(mine int, inch chan int, done chan int, count int) {
// First-number switch: true until first valid candidate arrives.
start := true
// Output channel for filtered numbers passed to next sieve stage.
ouch := make(chan int)
// Print current prime immediately upon startup.
fmt.Printf("%v ", mine)
}⚠️ 注意事项：
- gofmt 不解析注释内容，因此不会校验注释准确性或完整性；
- 行末注释若超过约 80 列总宽，可能被截断或影响可读性，应优先考虑拆分为前置注释；
- 使用 go vet 或静态分析工具（如 staticcheck）可辅助发现冗余或模糊注释。
总结：gofmt 的注释对齐是形式规范，而 Go 真正的注释约定在于分层表达意图——顶层用 godoc 描述接口契约，中层用独立注释阐明关键逻辑，底层让代码自解释。遵循此原则，才能写出既符合工具约束、又具备长期可维护性的 Go 代码。
