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

При присваивании map копируется не весь набор пар, а значение-дескриптор, связанное с одной внутренней таблицей. Поэтому две переменные после присваивания обращаются к одним данным: изменение существующей пары через одну переменную видно через другую.

Это не глубокая копия. Если нужна независимая map, её необходимо создать отдельно и перенести пары явным копированием.

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

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

Поэтому map ведёт себя как дескриптор управляемой внутренней структуры: переменная содержит доступ к таблице, а не независимый снимок всех пар. Это упрощает передачу map между функциями, но требует явно учитывать совместное владение данными.

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

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

Отдельный риск связан с nil-map. Чтение из nil-map допустимо и возвращает нулевое значение с признаком отсутствия ключа, но запись в неё приводит к панике: для записи сначала нужно создать map.

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

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

package main

import "fmt"

func main() {
    source := map[string]int{"a": 1}
    alias := source
    alias["a"] = 2
    alias["b"] = 3
    fmt.Println(source["a"], source["b"])
}

Программа выведет 2 3: переменные source и alias связаны с одним хранилищем. При этом присваивание другой map самой переменной не меняет исходную переменную: после переназначения alias она может указывать уже на другую таблицу, тогда как source продолжит ссылаться на прежнюю.

Глубокая копия требует явного создания map и копирования элементов. Для значений, содержащих вложенные ссылочные объекты, например срезы или другие map, копирование верхнего уровня всё равно не делает вложенные данные независимыми.

Map нельзя сравнивать между собой оператором ==; допустимо сравнение только с nil. Также совместное использование map между горутинами при конкурентной записи без синхронизации небезопасно и может привести к аварийному завершению программы. Для защиты применяют внешнюю синхронизацию либо подходящую специализированную структуру.

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

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

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

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

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

Что произойдёт, если удалить ключ через одну переменную map?

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

С точки зрения видимости данных — да: функция получает доступ к тому же хранилищу, и её изменения увидит вызывающий код. С точки зрения конкурентности — нет, если другая горутина одновременно читает или изменяет эту map без синхронизации; совместный доступ должен быть организован безопасно.
Почему присваивание nil-map другой переменной не делает её пригодной для записи?

При присваивании копируется тот же nil-дескриптор, поэтому обе переменные остаются nil-map. Чтение из них допустимо, но запись вызовет панику; для создания хранилища нужно явно инициализировать map, например через make, после чего записывать в неё.