Пока копался во внутренностях Go и сравнивал его с Rust, нашел полезное. Как известно, в Go фаза escape analysis решает, кто и куда будет аллоцирован - в кучу или на стек. Базовое правило простое: живешь в пределах функции - на стек, живешь дольше - на кучу. И Go, как язык самостоятельный, иногда может решить аллоцировать на кучу то, что мы ожидали на стеке. Плюс в том, что Go сам умеет объяснять, почему он это сделал. Достаточно запустить build с флагом -m: go build -gcflags='-m' ./... И компилятор выдаст подобный листинг: ./main.go:23:13: &user escapes to heap ./main.go:45:22: moved to heap: buf Что это значит: - escapes to heap - компилятор понял, что значение будет жить дольше функции и положил его в кучу - часто это происходит из-за того, что ты вернул указатель на локальную переменную или замкнул переменную в анонимную функцию: func outer() func(int) int { local := 10 return func(x int) int { return x * local // local уходит в кучу } } Иногда достаточно переписать сигнатуру или убрать лишний & - и аллокации исчезают, и это хороший способ выжать из Go больше перфоманса. dev notes | golang digest