Краткий ответ

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

Однако сама передача в any не гарантирует аллокацию: результат зависит от типа значения, контекста использования, escape analysis, инлайнинга и оптимизаций конкретной версии компилятора. Проверять гипотезу нужно по allocs/op, профилю аллокаций и диагностике компилятора, а не по одному факту наличия интерфейса.

Исторический контекст

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

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

Постановка проблемы

Предположим, обработчик принимает any, а вызывающий код передаёт крупную структуру. Если такие значения складываются в []any, возвращаются из функции или передаются в долгоживущий объект, копии могут сохраняться дольше исходного вызова.

Ошибочный вывод звучит так: «Любая передача значения в интерфейс выделяет память». Обратная ошибка тоже опасна: «Интерфейсы бесплатны». На практике стоимость зависит от динамического типа и от того, требуется ли интерфейсу отдельное адресуемое хранилище.

Подробное решение

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

Пример типичного источника дополнительных объектов:

package main

type Record struct {
    A, B, C, D int64
}

func collect(n int) []any {
    result := make([]any, 0, n)
    for i := 0; i < n; i++ {
        result = append(result, Record{A: int64(i)})
    }
    return result
}

При добавлении Record в []any значение должно быть скопировано в представление, пригодное для хранения внутри интерфейса. Кроме самих копий, память занимает массив интерфейсов: на 64-разрядной платформе элемент интерфейса обычно состоит из двух машинных слов, но точный внутренний layout не следует считать публичным API.

Аллокация не обязана происходить в каждом вызове. Компилятор может устранить её, если докажет, что интерфейс не покидает функцию или что объект можно безопасно разместить на стеке. Поэтому нужно сравнивать варианты с помощью go test -bench . -benchmem, анализировать allocs/op и B/op, а для причин использовать диагностические сообщения компилятора, включая отчёт об escape analysis.

Практические варианты оптимизации:

заменить []any на []Record, если набор типов известен и однороден;
передавать указатели на крупные объекты, если допустимы косвенный доступ и управление временем жизни;
использовать обобщённые функции, чтобы сохранить статический тип и избежать интерфейсного контейнера;
оставить интерфейс, если гибкость API важнее небольшой стоимости или аллокации не находятся в горячем пути.

Указатель уменьшает копирование крупной структуры, но добавляет косвенное обращение, ухудшает локальность данных и может увеличить давление на GC, если сами объекты становятся кучными. Поэтому оптимизация должна оцениваться профилем, а не только числом аллокаций.

Ситуация из практики

В системе пакетная обработка принимала []any, хотя фактически туда передавались записи одного типа. Профиль показал рост allocs/op после увеличения размера записи: интерфейсный контейнер хранил массив интерфейсов, а крупные значения требовали дополнительных копий.

Рассматривались три варианта. Сохранить []any было проще всего, но это оставляло копирование и зависимость от динамических типов. Перейти на []*Record уменьшало копирование, однако добавляло отдельные объекты, указатели и нагрузку на GC. Перейти на []Record сохраняло плотное размещение данных и статический тип, но подходило только после устранения необходимости в разнородных значениях.

Выбрали []Record: API действительно работал с одним типом, поэтому интерфейсная абстракция не давала пользы. После изменения проверили бенчмарки и профиль: число аллокаций и объём выделяемой памяти снизились, а поведение подтвердило, что причиной были не «интерфейсы вообще», а конкретное хранение крупных значений в интерфейсном контейнере.

Что кандидаты часто упускают

Всегда ли преобразование структуры в any создаёт объект в куче?

Нет. Аллокация зависит от того, должен ли интерфейс пережить текущий контекст и требуется ли ему отдельное хранилище. Escape analysis может доказать, что значение достаточно разместить на стеке, а оптимизации могут устранить копирование или сам интерфейсный объект. Поэтому утверждение проверяют на конкретном коде и версии компилятора.

Почему передача указателя в интерфейс тоже может ухудшить работу GC?

Указатель часто позволяет избежать копирования самой структуры, но объект, на который он указывает, может оказаться в куче. Кроме того, интерфейсное значение содержит указатель, который должен просматриваться сборщиком мусора; большое количество таких объектов и указателей увеличивает объём работы GC и может ухудшить локальность доступа.

Почему уменьшение allocs/op после отказа от any не всегда означает ускорение?

Интерфейсы могут быть необходимы для расширяемости, а статическая версия может привести к дублированию кода или более сложному API. Кроме того, вариант с указателями иногда быстрее по копированию, но медленнее из-за промахов кеша и обхода указателей. Итог нужно оценивать по задержкам, пропускной способности, B/op, профилю CPU и GC, а не по одной метрике аллокаций.