Что такое big-endian и little-endian

Что проверяют

Работали ли вы с бинарными данными руками. На Go вопрос всплывает у тех, кто пишет сетевые протоколы, разбирает форматы файлов или общается с железом, и ответ ждут с упоминанием стандартной библиотеки, а не пересказ учебника по архитектуре.

Как отвечать

Порядок байтов это способ разложить многобайтовое число в памяти или в потоке. Big-endian кладёт старший байт по младшему адресу, little-endian наоборот: младший байт идёт первым.

На практике little-endian у x86 и у ARM в обычном режиме, а big-endian закрепился в сетевых протоколах, за что его и называют сетевым порядком: так записаны длины и адреса в заголовках, так устроены многие бинарные форматы.

Важная оговорка: порядок касается только представления. Внутри программы число остаётся числом, арифметика и сравнения от порядка байтов не зависят, строки и срезы байтов не переворачиваются. Разница вылезает ровно там, где память или поток интерпретируются как число.

В Go ручных преобразований вроде htonl нет и не нужно, порядок задаётся явно готовыми значениями из encoding/binary.

buf := make([]byte, 4)
binary.BigEndian.PutUint32(buf, 0x12345678) // 12 34 56 78
n := binary.LittleEndian.Uint32(buf)        // прочитали как 0x78563412

Вывод для собеседования: порядок фиксируется в спецификации протокола и записывается в коде явным кодеком, а не берётся от машины.

Где спотыкаются

Думают, что переворачиваются биты внутри байта. Порядок бит в байте одинаков везде, меняется только порядок самих байтов в многобайтовом значении.

Сериализуют структуру через binary.Write и удивляются результату. Функция работает только с типами фиксированного размера: тип int, срезы переменной длины и строки она не возьмёт, а поля структуры запишет подряд, без выравнивания и без имён.

Полагаются на порядок хоста, потому что «везде x86», и пишут собственные сдвиги вместо готового кодека. Такой код ломается при первом же обмене с внешней системой, а найти причину по битому числу в логе тяжело.