`binary.varint` 专为有符号整数设计，它将输入字节按 zigzag 编码规则解码：先右移一位再根据最低位决定是否取反；而 `byte` 本质是 `uint8`（无符号），直接用 `varint` 会导致数值被错误解析（如 18 变成 9）。应改用 `binary.uvarint` 解码无符号值。
在 Go 的 encoding/binary 包中，Varint 和 Uvarint 虽然都用于变长整数编码/解码，但语义截然不同：
- binary.Uvarint([]byte)：解码 无符号 整数（uint64），适用于原始字节流中存储的正整数值（如 byte、uint8、uint16 等）；
- binary.Varint([]byte)：解码 有符号 整数（int64），内部采用 ZigZag 编码，专为 Protocol Buffers 等场景优化，可高效表示负数且避免符号位浪费。
你示例中的 myByte = 18 是一个 uint8，二进制为 00010010。当调用 binary.Varint 时，其底层逻辑如下（摘自 Go 源码）：
func Varint(buf []byte) (int64, int) {
ux, n := Uvarint(buf) // 先以无符号方式读取 → ux = 18
x := int64(ux >> 1) // 右移一位 → 18 >> 1 = 9（即 00010010 → 00001001）
if ux&1 != 0 { // 检查原值最低位是否为 1
x = ^x // 若是，则按 ZigZag 规则取反（表示负数）
}
return x, n
}
由于 18 & 1 == 0，跳过取反，最终返回 9 —— 这正是你观察到的“结果减半”的根本原因：ZigZag 解码强制将输入视为已编码的有符号值，而你的字节并未经过 ZigZag 编码。
✅ 正确做法：对原始无符号字节（如 []byte{18}），始终使用 Uvarint：
package main
import (
"fmt"
"encoding/binary"
)
func main() {
var myByte byte = 18
array := []byte{myByte}
// ❌ 错误：Varint 期望 ZigZag 编码的有符号值
// val, n := binary.Varint(array) // → value: 9, num bytes: 1
// ✅ 正确：Uvarint 直接解码无符号整数
val, n := binary.Uvarint(array) // → value: 18, num bytes: 1
fmt.Printf("value: %d, num bytes: %d/n", val, n)
}
⚠️ 注意事项：
- Uvarint 要求输入字节是标准的 unsigned LEB128 编码（Little-Endian Base 128），单字节 18 符合该格式（最高位为 0，表示结束）；
- Varint 的输入必须是经 ZigZag 编码的字节（例如 int32(-1) 的 ZigZag 编码是 0xFF, 0x01），直接传入原始 uint8 值属于类型误用；
- 若需序列化有符号整数，请先用 binary.PutVarint 编码，再用 binary.Varint 解码，确保编解码逻辑对称。
总结：类型匹配是关键——byte → uint8 → Uvarint；int64（含负数）→ Varint（配合 ZigZag）。混淆二者将导致静默的逻辑错误，而非 panic，务必在协议设计和序列化层明确数据的符号性。