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

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

Поэтому в Go нет висячей ссылки из-за выхода локальной переменной из области видимости. Когда указатель и все другие ссылки на объект исчезают, объект может быть освобождён сборщиком мусора.

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

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

Чтобы автоматическое управление памятью не требовало от разработчика вручную выбирать между стеком и кучей, компилятор применяет escape analysis — анализ выхода объектов за границы локальной области использования. Он отделяет семантическую корректность программы от конкретного места размещения данных.

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

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

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

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

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

В простом случае компилятор размещает такой объект в куче. Сборщик мусора затем сохраняет объект живым, пока существует достижимый указатель. После этого указатель становится недействующим с точки зрения логики программы, но не возникает обращения к уже освобождённой памяти: память управляется средой выполнения.

package main

func makeValue() *int {
    value := 10
    return &value
}

func main() {
    pointer := makeValue()
    *pointer = 20
}

После makeValue переменная value продолжает существовать, потому что на неё ссылается pointer. Возврат указателя безопасен; при этом нельзя делать вывод о фактическом размещении объекта только по исходному коду.

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

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

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

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

Результат — безопасное время жизни состояния без ручного освобождения памяти. При росте нагрузки решение проверяют профилированием аллокаций и сборки мусора, а не заменяют указатели исключительно из-за предположения о дорогом heap allocation.

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

Обязательно ли взятие адреса локальной переменной приводит к выделению в куче?

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

Да, если объект или содержащий его массив остаётся достижимым через этот указатель. Компилятор должен обеспечить нужное время жизни соответствующих данных. При этом изменение исходной структуры данных, повторное присваивание среза или операции, меняющие его backing array, могут иметь отдельные семантические последствия и не должны смешиваться с вопросом времени жизни.
Почему указатель после завершения функции не требует ручного освобождения?

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