Структура

type stringStruct struct {
    str unsafe.Pointer   // на первый байт
    len int              // длина в байтах
}
unsafe.Sizeof("любая строка")   // 16 на amd64 - размер заголовка

От []byte отличие одно: нет cap. Ёмкость не нужна, строка не растёт. Данные лежат в read-only секции бинаря (для литералов), в куче (результат конкатенации, конверсии) или в стеке, если escape-анализ решил, что значение не утекает.

Зачем иммутабельность

1. Подстрока без копии. s[a:b] отдаёт новый заголовок на тот же буфер: O(1), ноль аллокаций. Будь строки изменяемыми, так было бы небезопасно.
2. Конкурентность. Неизменяемое значение читается любым числом горутин без синхронизации. Это единственный «составной» тип Go с такой гарантией.
3. Ключи мапы. Хеш считается один раз и не может «протухнуть» из-за изменения содержимого.
4. Дешёвая передача. Копия строки весит 16 байт независимо от длины данных.
5. Интернирование литералов. Компилятор кладёт одинаковые литералы в одну read-only область; запись туда была бы SIGSEGV на уровне ОС.

s := "hello"
// s[0] = 'H'          // ошибка компиляции: cannot assign to s[0]
b := []byte(s); b[0] = 'H'; s2 := string(b)   // через копию

Цена конверсий

• []byte(s) и string(b) идут через mallocgc + memmove: O(n), одна аллокация. Копия обязательна, иначе изменяемый срез поменял бы «неизменяемую» строку.
• []rune(s) декодирует UTF-8 целиком и строит массив int32: O(n) по времени и до 4× памяти для ASCII.
• string(rs) кодирует каждую руну обратно: O(n), одна аллокация.
• s[a:b] стоит ноль аллокаций, только новый заголовок.

Где компилятор убирает копию

m[string(b)]                       // ключ мапы - без аллокации
if string(b) == "hello" { }        // сравнение - без аллокации
for _, r := range string(b) { }    // range - без аллокации
switch string(b) { case "a": }     // switch - без аллокации
io.WriteString(w, s)               // вместо w.Write([]byte(s)) - без аллокации

Правило одно: если временная строка не переживает выражение, компилятор её не материализует. Но как только результат сохраняется в переменную, попадает в структуру или уходит в интерфейс, копия неизбежна.

Как избегать конверсий на практике

• Выбери один тип и веди его через весь путь данных: []byte для I/O-пайплайнов, string для доменной логики.
• Пользуйся зеркальными API: bytes.Contains вместо strings.Contains(string(b), …); strconv.AppendInt вместо []byte(strconv.Itoa(…)).
• В горячем пути выручат unsafe.String и unsafe.Slice, но только когда профиль это доказал и инварианты понятны.

s := "Привет"
len(s)                        // 12 - кириллица по 2 байта
utf8.RuneCountInString(s)     // 6
len([]rune(s))                // 6, но с аллокацией: ради счёта так не делают

Три способа пройти по строке

// 1) По рунам: range декодирует UTF-8, i это байтовое смещение
for i, r := range s {
    fmt.Printf("%d:%c ", i, r)     // 0:П 2:р 4:и 6:в 8:е 10:т
}

// 2) По байтам, когда работаешь с бинарём или ASCII-протоколом
for i := 0; i < len(s); i++ {
    _ = s[i]                       // uint8
}

// 3) Через []rune, когда нужен произвольный доступ по индексу символа
rs := []rune(s)
_ = rs[3]                          // аллокация: оправдана, только если индексируешь много раз

Что важно про UTF-8

• Кодировка переменной длины: 1 байт на ASCII, 2 на кириллицу и греческий, 3 на CJK и большинство символов, 4 на эмодзи.
• Продолжающие байты всегда начинаются с 10, поэтому границу символа можно найти из любой позиции и идти по строке назад.
• Подстрока ASCII не может «случайно» совпасть с куском многобайтового символа, поэтому strings.Split(s, "/") безопасен без Unicode-парсинга.
• Невалидные байты range отдаёт как utf8.RuneError (U+FFFD) длиной 1 байт, не паникуя.

Обрезка строки по длине - типичная задача

// Плохо: разрежет руну пополам, в выводе появится U+FFFD
func truncBad(s string, n int) string { if len(s) > n { return s[:n] }; return s }

// Хорошо: режем по границе руны, без аллокации
func trunc(s string, n int) string {
    if utf8.RuneCountInString(s) <= n { return s }
    cnt := 0
    for i := range s {              // i - смещение начала очередной руны
        if cnt == n { return s[:i] }
        cnt++
    }
    return s
}

s := "Привет"
fmt.Printf("%T %v\n", s[0], s[0])   // uint8 208 - первый байт буквы "П" (0xD0)
fmt.Printf("%c\n", s[0])            // Ð - 208 прочитан как кодовая точка U+00D0
fmt.Println(s[0:2])                 // "П" - два байта вместе дают букву

// А range декодирует и даёт rune:
for i, r := range s {
    fmt.Printf("%d %T %c\n", i, r, r)   // 0 int32 П ; 2 int32 р ; ...
    break
}

Почему так

Строка хранит байты, и len(s) считает именно их. Если бы s[i] возвращало руну, индексация стала бы O(n) (пришлось бы декодировать всё от начала), а len перестал бы соответствовать диапазону индексов. Go выбрал прямую байтовую модель, дешёвую и предсказуемую. Расплата в том, что за символами надо ходить через range или []rune.

Практические следствия

• Для ASCII разницы нет: там байт и есть символ, и s[i] работает как ожидаешь.
• Для не-ASCII s[i] в цикле даст мусор: половинки многобайтовых последовательностей.
• s[a:b] режет по байтам и легко разорвёт руну, а при печати вылезет U+FFFD.
• «Первый символ» берут так:

r, size := utf8.DecodeRuneInString(s)   // руна и её длина в байтах, без аллокации
fmt.Printf("%c занимает %d байт\n", r, size)   // П занимает 2 байт

// Или через range с немедленным выходом:
for _, r := range s { first = r; break }

// А не так:
// first := rune(s[0])   // 208 - это не буква

Что происходит при s += x

Компилятор вызывает runtime.concatstrings: считает суммарную длину, выделяет новый буфер, копирует в него оба куска. Старая строка становится мусором. На n итерациях копируется n(n+1)/2 байт и остаётся n мусорных буферов, которые вдобавок нагружают GC.

Оговорка: a + b + c + d одним выражением превращается в один вызов concatstrings, то есть в одну аллокацию. Плохо именно накопление в цикле.

var b strings.Builder
b.Grow(totalLen)                 // одна аллокация на всё
for _, p := range parts {
    b.WriteString(p)             // append в []byte, без копии строки
}
return b.String()                // unsafe-конверсия без копии буфера

Почему Builder быстрее bytes.Buffer для строк

bytes.Buffer.String() делает string(b.buf[off:]), то есть честную копию. strings.Builder.String() возвращает unsafe.String(&b.buf[0], len(b.buf)) без копии, и это безопасно: Builder гарантирует, что после String() в буфер уже никто не пишет (запись после копирования Builder ловится паникой). На мегабайтной строке одна лишняя копия чувствуется.

func extractID(body string) string {
    return body[10:20]    // 10 байт, а держат весь body
}
cache[key] = extractID(hugeBody)   // в кэше «10 байт», в куче - весь body

Почему GC не может помочь

Сборщик работает с гранулярностью объекта: буфер строки лежит в куче одним блоком. Если на него указывает хотя бы один живой указатель, жив весь блок. Обрезать его GC не умеет: в Go нет перемещающего сборщика и нет «частичного освобождения» объекта.

Три способа починить

// 1) strings.Clone - Go 1.18+, самый честный способ
small := strings.Clone(body[10:20])

// 2) Конверсия туда-обратно, так жили до Clone
small = string([]byte(body[10:20]))

// 3) Не создавать большую строку вообще: читать потоково
sc := bufio.NewScanner(r)
for sc.Scan() {
    line := sc.Text()      // Text() уже делает копию, Bytes() нет: буфер переиспользуется
}

Где это ловится в проде

• strings.Split, strings.Fields, strings.TrimSpace возвращают подстроки, а не копии. Разобрали лог-строку на 8 КБ, сохранили одно поле в мапу, держим 8 КБ.
• bytes.Split и bufio.Scanner.Bytes(): то же самое со срезами, причём у Scanner буфер ещё и переиспользуется между строками, так что данные протухнут.
• Парсинг HTTP-ответа: достали id слайсингом из тела на мегабайт, удержали мегабайт на каждую запись.
• regexp.FindStringSubmatch тоже отдаёт подстроки исходной строки.

Как диагностировать

$ go tool pprof -inuse_space http://localhost:6060/debug/pprof/heap
(pprof) top
# симптом: почти вся живая память в одном месте аллокации большого буфера
# (os.ReadFile, io.ReadAll, http body), хотя логически хранится мало

Как устроено ==

Компилятор разворачивает сравнение строк в проверку длин (разошлись, сразу false), затем в сравнение указателей (совпали, сразу true), и только потом в runtime.memequal, который идёт по машинным словам, с SIMD там, где он доступен. Оператор < сравнивает лексикографически по байтам; для UTF-8 это совпадает с порядком кодовых точек, но не с алфавитным порядком языка.

"Z" < "a"                  // true: 0x5A < 0x61 - заглавные раньше строчных
"ёлка" < "яблоко"          // сравниваются байты UTF-8, а не «русский алфавит»
// для человеческого порядка нужен golang.org/x/text/collate

Почему EqualFold, а не ToLower

1. Аллокации. ToLower создаёт две новые строки; EqualFold идёт по обеим строкам параллельно и не аллоцирует вообще.
2. Ранний выход. На первом различии сразу false, остаток не читается.
3. Корректность. Unicode определяет отдельную операцию case folding, спроектированную именно для сравнения. Она не равна «привести к нижнему регистру»: у греческой сигмы две строчные формы (σ и ς), у турецкого I своя пара, у немецкого ß отдельные правила.

strings.EqualFold("Go", "GO")           // true
strings.EqualFold("ПРИВЕТ", "привет")   // true
strings.EqualFold("Σίσυφος", "ΣΊΣΥΦΟΣ") // true - обе сигмы свернутся правильно
strings.EqualFold("Straße", "STRASSE")  // false - simple folding не разворачивает ß в ss

Когда нужен НЕ ==