Это потому, что вы создаете fullHashInputBytes
, добавляя к firstHalfinput1Bytes
first:
fullHashInputBytes := append(firstHalfinput1Bytes, input2Bytes...)
, который является частью input1bytes
:
firstHalfinput1Bytes := input1bytes[:8]
Итак, первый append может перезаписать содержимое input1bytes
с индексами выше 7, что на самом деле является содержимым 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
:
input1bytes := []byte(input1)
fmt.Println(cap(input1bytes))
(Вы можете прочитать Подробнее об этом здесь: Объединение двух фрагментов в Go).
Преобразование []byte(input)
гарантирует только байты input1
, но значение c не указывает, насколько большой должна быть емкость полученного среза. И это может зависеть от платформы / архитектуры. На игровой площадке Go приведенное выше преобразование приводит к capacity = 16
, на моей локальной архитектуре amd64
я получаю capacity = 32
.
Один последний кусок: емкость, используемая для среза результата []byte(input)
преобразование может зависеть от того, что вы делаете с результирующим срезом. Компилятор может принять решение использовать меньшую емкость, если вы передадите ее fmt.Println()
, так как это сигнализирует о том, что срез может исчезнуть. Опять же, решение, принятое компилятором, не в ваших руках.
Не полагайтесь на такие вещи, не пишите код, который опирается на емкость результирующего фрагмента преобразования. Сделайте это «чистым» способом: не добавляйте к firstHalfinput1Bytes
, а к новому срезу.