这是因为您
fullHashInputBytes通过添加到
firstHalfinput1Bytesfirst 来创建：
fullHashInputBytes := append(firstHalfinput1Bytes, input2Bytes...)
这是其中的一部分
input1bytes：
firstHalfinput1Bytes := input1bytes[:8]
因此，第一个附录可能会覆盖
input1bytes索引高于7 的at的内容，实际上是以下内容
secondHalfinput1Bytes：
secondHalfinput1Bytes := input1bytes[8:16]
因此，稍后还要添加
secondHalfinput1Bytes到时
fullHashInputBytes，可能最终会添加不同的内容。
这很可能不是您想要的。
如果您做到“干净”：
var fullHashInputBytes []bytefullHashInputBytes = append(fullHashInputBytes, firstHalfinput1Bytes...)fullHashInputBytes = append(fullHashInputBytes, input2Bytes...)// OPTIonAL print doesn't change anything:fmt.Println("fullHashInputBytes", fullHashInputBytes)// ...rest of your appends...如果在本地或Go Playground上运行，则输出将相同。
为什么行为异常？
您的第一个追加
input1bytes是否被覆盖取决于该追加是否可以“就地”执行而不必分配新的后备数组，这取决于
firstHalfinput1Bytes“”从
input1bytes以下继承的容量：
input1bytes := []byte(input1)fmt.Println(cap(input1bytes))
该转换
[]byte(input)只保证拥有的字节
input1，但该规范并没有规定所产生的切片的容量有多大应该的。它可能取决于平台/体系结构。在Go
Playground上，上述转换导致
capacity = 16我在本地
amd64建筑上得到
capacity = 32。
最后一件：
[]byte(input)转换结果切片所使用的容量可能取决于您对结果切片的处理方式。如果将其传递给编译器，则编译器可能会决定使用较低的容量，
fmt.Println()因为这表明片可能会逃逸。再次，由编译器做出的决定是您无法控制的。
不要依靠这种东西，不要编写依赖于转换结果片的容量的代码。以“干净”的方式进行：不要追加到
firstHalfinput1Bytes新的切片上。
