any и type assertion в Go

Две формы, и разница драматична

Форма с одним результатом - v := i.(int) - при несовпадении типа паникует. Форма с двумя - v, ok := i.(int) - при несовпадении возвращает нулевое значение и false, не паникуя. Синтаксис отличается на одну переменную, поведение - на упавший процесс.

Первая форма уместна там, где несовпадение означает ошибку в собственном коде и падать правильно: сразу после того, как ты сам положил значение в any, или в месте, где инвариант гарантирован.

Вторая - везде, где значение пришло снаружи: из декодированного JSON, из чужого API, из кеша с интерфейсными значениями. Проверено на утверждении к интерфейсу, которого тип не реализует: ok равен false, никакой паники, дальше идёт нормальная обработка.

// Утверждать можно и к интерфейсу, а не только к конкретному типу: v, ok := x.(io.Closer) отвечает на вопрос «а умеет ли эта штука закрываться». Так в стандартной библиотеке проверяют дополнительные возможности значения, не требуя их от всех.

v := i.(int)        // при несовпадении - паника
v, ok := i.(int)    // при несовпадении - 0 и false

if c, ok := x.(io.Closer); ok {
    defer c.Close()   // умеет закрываться - закроем
}

Цена укладки в интерфейс

Положить значение в интерфейс - не бесплатная операция. Интерфейс хранит указатель на значение, поэтому значение, которое раньше жило на стеке, обычно уезжает в кучу. Это видно в выводе компилятора с флагом -gcflags=-m строчкой про escapes to heap.

Самый массовый случай - аргументы fmt.Println и подобных функций: они принимают ...any, значит каждый аргумент укладывается в интерфейс и уходит в кучу. В горячем цикле это заметно на профиле аллокаций.

Отсюда правило: any хорош на границах, где типы действительно заранее неизвестны - декодирование, универсальные кеши, логирование. Внутри своей логики его лучше не тащить: теряется проверка компилятором и добавляется работа сборщику.

// С Go 1.18 у any появилась честная альтернатива для случая «любой тип, но один и тот же» - дженерики. Функция с параметром типа сохраняет типизацию и не требует утверждений на выходе.

JSON: почему число стало float64

Классическая история. Декодируешь JSON в map[string]any, лезешь за полем с числом, утверждаешь его к int - и получаешь панику или false. Причина в том, что в JSON нет отдельного целочисленного типа, и стандартный декодер укладывает любое число в float64.

Значит утверждать надо к float64 и приводить дальше самому. И тут же вылезает вторая беда: float64 точно представляет целые примерно до девяти квадриллионов, а большие идентификаторы за этой границей молча теряют младшие разряды. Идентификатор превращается в соседний, и ошибка находится в проде.

Лечится двумя способами. Первый и правильный - декодировать в структуру с нужными типами полей, а не в map[string]any. Второй, когда структура заранее неизвестна, - декодер с опцией UseNumber: тогда числа приходят типом json.Number, из которого можно достать и целое, и строку без потерь.

// Общее правило: map[string]any для JSON - крайняя мера. Структура даёт и типы, и валидацию имён полей, и документацию формата в одном месте.

json.Number

строковое представление числа из JSON; позволяет достать большое целое без потери точности

Как отвечать: «Как достать значение из any и что будет при неверном типе?»

Утверждением типа, и у него две формы. Короткая, v := i.(int), при несовпадении паникует - её беру только там, где несовпадение означает ошибку в моём собственном коде и падать правильно. Форма с двумя результатами, v, ok := i.(int), при несовпадении возвращает нулевое значение и false, ничего не роняя - её использую везде, где значение пришло снаружи: из JSON, из чужого API, из кеша. Утверждать можно и к интерфейсу, например к io.Closer, чтобы спросить «а умеет ли эта штука закрываться» - так в стандартной библиотеке проверяют дополнительные возможности. Отдельно назову самую частую ловушку: если декодировать JSON в map[string]any, все числа приходят как float64, потому что в JSON нет отдельного целого типа. Утверждение к int там всегда даст false, а большие идентификаторы ещё и потеряют точность. Правильное лечение - декодировать в структуру с нужными типами, а если структура заранее неизвестна, включать у декодера режим json.Number.

Обе формы названы с критерием выбора, показано утверждение к интерфейсу и разобрана самая частая практическая ловушка вместе с двумя способами её убрать.

На чём валят

• −Используют короткую форму утверждения для внешних данных и роняют процесс.
• −Утверждают число из JSON к int и удивляются, что там float64.
• −Теряют точность больших идентификаторов, прошедших через float64.
• −Тащат any вглубь логики вместо структур или дженериков.
• −Забывают, что укладка в интерфейс отправляет значение в кучу.
• −Не проверяют ok и работают с нулевым значением как с настоящим.