google.golang.org/protobuf的AppendVarint为何用append而非预构造切片

首先你提出的直接构造切片的写法存在核心语义错误，完全不符合函数的设计要求：

// 官方函数签名明确是Append语义：将v的varint编码追加到输入切片b的尾部
func AppendVarint(b []byte, v uint64) []byte

你给出的替代写法b = []byte{...}直接用新生成的切片覆盖了原输入切片b，会把b中已经存储的所有原有数据全部清空，完全违背了Append的设计目的——比如序列化protobuf消息时，需要连续把多个字段的编码追加到同一个字节切片里，用你的写法之前写入的内容会全部丢失，根本无法满足实际使用需求。

关于append的开销问题 #

你担心的append内存拷贝开销实际上在绝大多数场景下可以忽略，甚至比手动构造切片性能更高：

• 只要调用方传入的切片剩余容量（cap(b) - len(b)）足够放下varint编码（uint64的varint编码最长只有10字节），append操作不会触发任何内存分配和扩容，只是直接把字节写入底层数组的空闲位置，仅修改切片的len属性，开销几乎为0。
• 官方实现的每个switch分支都是一次性把对应长度的所有编码字节传给append，而非逐个append单个字节，Go编译器会对这种多参数append做优化，直接批量拷贝字节，不存在多次拷贝的开销。
• 就算遇到切片容量不足需要扩容的场景，append的扩容逻辑是经过Go runtime深度优化的，比开发者手动申请内存、拷贝数据的效率更高。
• 就算你想先构造编码切片再追加到原切片后面，也要额外做一次b = append(b, tempSlice...)，反而多了一次临时切片的内存分配和拷贝开销，性能比现有实现更差。

为什么不提前计算长度再写入 #

确实可以提前算出varint的编码长度，先扩容再通过下标赋值写入，但这种写法和现有append写法的性能差异极小，官方选择现有写法主要是出于可读性和可维护性考虑：

• 现有switch分支结构和varint的编码规则完全对应，每个分支对应一个编码长度，直接append对应字节，逻辑一目了然，新人看代码很容易理解，后续修改也不容易出错。
• 如果先算长度再写入，需要额外新增一段判断v大小计算编码长度的逻辑，再扩容、再按下标赋值，代码复杂度反而更高，获得的性能提升却可以忽略，完全没有必要。

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