附加切片后计算 sha256 会给出不同的结果，具体取决于我之前是否打印出切片

在使用 Go 语言计算 SHA256 哈希时，附加切片到另一个切片可能会导致意外结果。这是因为在将切片附加到已存在的切片时，Go 编译器可能会覆盖附加切片的某些部分。为了避免这种情况，建议使用“干净”的方式，即创建新切片并逐个附加切片，而不是附加到现有切片。

我正在根据多个字符串计算 sha256。我以特定方式将它们转换为字节切片并将它们全部附加在一起，然后使用内置库计算哈希值。然而，根据我是否在计算 sha256 之前打印出切片，我会奇怪地得到不同的结果。在演示中测试它时，我无法重现它。

可以在 https://play.golang.org/p/z8xkx-p9hug 上查看并运行经过测试的代码，在这两种情况下它实际上给出了相同的结果。

func gethash(input1 string, input2hex string, input3hex string, input4 string) (string, error) {
    input1bytes := []byte(input1)
    firsthalfinput1bytes := input1bytes[:8]
    secondhalfinput1bytes := input1bytes[8:16]

    input4bytes := []byte(input4)

    input3bytes, err := hex.decodestring(input3hex)
    if err != nil {
        fmt.println("err " + err.error())
    }

    input2bytes, err := hex.decodestring(input2hex)
    if err != nil {
        fmt.println("err " + err.error())
    }

    fullhashinputbytes := append(firsthalfinput1bytes, input2bytes...)
    // this is the optional print which changes output locally:
    fmt.println("fullhashinputbytes", fullhashinputbytes)
    fullhashinputbytes = append(fullhashinputbytes, secondhalfinput1bytes...)
    fullhashinputbytes = append(fullhashinputbytes, input3bytes...)
    fullhashinputbytes = append(fullhashinputbytes, input4bytes...)
    sha256 := sha256.sum256(fullhashinputbytes)
    for i := 0; i < 8; i++ {
        sha256[i+16] ^= sha256[i+24]
    }
    hash := hex.encodetostring(sha256[:24])
    fmt.println("hash", hash)
    return hash, nil
}

演示上的日志是

hello, playground
fullhashinputbytes [84 72 73 83 73 83 78 79 30 0 22 121 57 203 102 148 210 196 34 172 210 8 160 7]
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c

但是如果我在本地运行完全相同的代码（只需将其复制粘贴到 main.go 中并执行 go run main.go 或 go build . 和 ./test ）我得到 ​​p>

Hello, playground
fullHashInputBytes [84 72 73 83 73 83 78 79 30 0 22 121 57 203 102 148 210 196 34 172 210 8 160 7]
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c
hash d2de4ffb4e8790b8fd1ceeba726436fd97875a5740c27b47

我使用的是 go 版本 1.13.4，但 1.10.4 也有同样的问题。我在本地计算机上以及部署到我们的服务器时也遇到了同样的问题。

解决方案

这是因为您通过先附加到 firsthalfinput1bytes 来创建 fullhashinputbytes：

fullhashinputbytes := append(firsthalfinput1bytes, input2bytes...)

这是 input1bytes 的一部分：

firsthalfinput1bytes := input1bytes[:8]

所以第一个追加可能会覆盖索引大于7的input1bytes的内容，这实际上是secondhalfinput1bytes的内容：

secondhalfinput1bytes := input1bytes[8:16]

因此，稍后当您还将 secondhalfinput1bytes 附加到 fullhashinputbytes 时，您最终可能会附加不同的内容。

这很可能不是您想要的。

如果你做得“干净”：

var fullhashinputbytes []byte
fullhashinputbytes = 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“继承”的： p>

input1bytes := []byte(input1)
fmt.Println(cap(input1bytes))

（您可以在这里阅读更多详细信息：Concatenate two slices in Go）。

conversion []byte(input) 仅保证具有 input1 的字节，但规范并未规定结果切片的容量应该有多大。这可能取决于平台/架构。在 go 演示中，上述转换结果为 capacity = 16，在我本地的 amd64 架构上，我得到 capacity = 32。

最后一点：用于 []byte(input) 转换结果切片的容量可能取决于您对结果切片的处理方式。如果将其传递给 fmt.println()，编译器可能会决定使用较低的容量，因为这表明切片可能会逃逸。再说一次，编译器做出的决定不在你的掌控之中。

不要依赖这样的东西，不要编写依赖于转换结果切片容量的代码。以“干净”的方式进行：不要附加到 firsthalfinput1bytes 而是附加到一个新切片。

理论要掌握，实操不能落！以上关于《附加切片后计算 sha256 会给出不同的结果，具体取决于我之前是否打印出切片》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！