为什么Golang的hchan结构体中closed字段采用uint32类型？

给出的hchan结构体定义片段如下：

type hchan struct {
    qcount   uint           // 队列中的总数据量
    dataqsiz uint           // 环形队列的大小
    buf      unsafe.Pointer // 指向长度为dataqsiz的元素数组
    elemsize uint16
    closed   uint32
// 其余字段省略
}

核心原因有三点：

• 原子操作的跨架构兼容性
  closed字段的读写全程使用原子操作保证并发安全，Go runtime内置的原子操作函数（如atomic.StoreUint32、atomic.LoadUint32）对所有支持的架构都做了兼容，可直接保证操作的原子性。如果使用int8等更小的类型，部分老旧的32位架构不支持单字节的原子指令，需要额外做兼容处理，反而会引入额外开销和竞态风险。
• 内存对齐不会带来额外空间收益
  按照Go的内存对齐规则，hchan结构体的对齐粒度由其中最长的字段（64位系统下为unsafe.Pointer类型的buf，占8字节）决定。当前elemsize为uint16占2字节，后面放uint32的closed时，只需要补2字节的padding即可凑满8字节的对齐单位；如果换成int8类型，虽然字段本身少占3字节，但为了对齐后面的8字节字段，依然需要补5字节的padding，整个结构体的总大小不会有任何变化，完全没有空间收益。
• 可扩展性与风格统一
  Go runtime的开发中，状态类字段普遍使用uint32类型，一方面是统一编码风格降低维护成本，另一方面也为后续可能的状态扩展预留了空间，即使目前closed只有0（未关闭）和1（已关闭）两个取值，保留更大的类型范围可以避免后续需求变更时修改字段类型带来的大面积代码调整。

内容的提问来源于stack exchange，提问作者ZenC