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

Программа завершится с паникой во время выполнения на выражении a == b. Интерфейсные значения можно сравнивать, но если их динамические типы совпадают и этот тип несравним, сравнение вызывает панику.

В примере динамический тип обоих значений — data, а data является именованным типом на основе среза. Срезы несравнимы с помощью ==, поэтому сравнение двух значений Box также невозможно.

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

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

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

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

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

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

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

При сравнении a == b Go сначала рассматривает динамические типы интерфейсных значений.

Если динамические типы различаются, результат сравнения — false.
Если один интерфейс равен nil, сравнение с ним безопасно и даёт false для непустого интерфейса.
Если динамические типы совпадают, Go сравнивает динамические значения. Их тип должен быть сравнимым.

К сравнимым относятся, например, числа, строки, указатели, каналы, интерфейсы, массивы сравнимых элементов и структуры, состоящие только из сравнимых полей. Срезы, карты и функции несравнимы; их можно сравнить только с nil там, где это разрешено для самого конкретного типа.

Тип data имеет метод Value, поэтому удовлетворяет Box. Однако наличие метода никак не делает его базовый срез сравнимым. При присваивании data{1} в Box сохраняются динамический тип data и значение среза; интерфейс не преобразует срез в сравнимую структуру.

package main

import (
	"fmt"
	"reflect"
)

type data []int

type Box interface{ Value() any }
func (data) Value() any { return nil }

func main() {
	var a Box = data{1}
	var b Box = data{1}
	fmt.Println(a == nil)              // false
	fmt.Println(reflect.DeepEqual(a, b)) // true
}

reflect.DeepEqual рекурсивно сравнивает содержимое срезов, поэтому в этом примере не вызывает панику. Но это не универсальная замена ==: у него отдельные правила для nil, указателей, карт, функций и других составных значений.

Если нужна проверка равенства по бизнес-смыслу, надёжнее определить явную операцию сравнения или использовать сравнимый ключ, например строковый идентификатор. Не следует бездумно применять reflect.DeepEqual в горячем пути или считать его эквивалентом логического равенства доменных объектов.

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

Сервис хранит значения разных типов в map[string]Box, а перед записью пытается проверить, что новое значение не совпадает со старым через old == new. Для строк и чисел код работает, но при передаче объекта с полем-срезом возникает паника в рабочем процессе.

Рассматривались три варианта:

Сравнивать интерфейсы через ==. Это быстро и просто, но небезопасно для несравнимых динамических типов.
Использовать reflect.DeepEqual. Это поддерживает составные значения, но задаёт технические, а не обязательно доменные правила равенства и может быть затратнее.
Добавить в интерфейс метод вроде Equal(Box) bool или вынести отдельный сравнимый идентификатор. Это требует доработки типов, зато явно фиксирует смысл равенства.

Выбрано сравнение по стабильному идентификатору сущности. Оно не зависит от наличия срезов или карт внутри объекта, не вызывает паники и соответствует бизнес-правилу: две версии считаются относящимися к одной сущности, если совпадает её идентификатор.

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

Паникует ли сравнение интерфейса с nil, если внутри находится срез?

Нет. Например, var x any = []int{1}; x == nil даст false. У интерфейса x есть динамический тип, поэтому он не равен nil; сравнение не требует сравнивать два значения типа []int между собой.
Что произойдёт, если динамические типы интерфейсов различаются?

Сравнение обычно даст false без паники, даже если один из динамических типов несравним. Например, значения с динамическими типами []int и map[string]int не имеют одинакового динамического типа, поэтому до сравнения самих срезов или карт дело не доходит. Паника возникает при совпадении динамического типа, когда требуется сравнить два несравнимых значения этого типа.
Можно ли сделать срез сравнимым, объявив новый именованный тип?

Нет. Именованный тип type data []int получает методы и отличается по имени, но сохраняет свойства базового типа среза: он остаётся несравнимым. Для сравнения по == нужно хранить сравнимое представление, например массив фиксированной длины, строковый ключ или указатель, понимая при этом, что сравнение указателей сравнивает адреса, а не содержимое объектов.