❓ Как работает iota в блоке констант

iota начинает с нуля в начале блока const и увеличивается на единицу для каждой новой строки. После присвоения значения переменной, можно не указывать iota снова для следующих переменных, и Go самостоятельно применит инкремент.

const (
    A = iota
    B
    C
    D
)
// A = 0, B = 1, C = 2, D = 3

Важно помнить, что iota применяется только внутри блока const. Если создать второй блок const, то счетчик снова начинает с нуля. Каждый блок независим.

🐸 Библиотека Go для собеса

❓ Почему http.ListenAndServe(":8080", nil) считается плохой практикой

nil означает DefaultServeMux, глобальный роутер. В него может зарегистрировать хендлер любой импортированный пакет, например net/http/pprof делает это в init. Так наружу случайно утекают отладочные ручки.

У такого сервера нет тайм аутов. Правильнее создать свой Server и свой ServeMux.

Правильный вариант:

srv := &http.Server{
  Addr:              ":8080",
  Handler:           mux,
  ReadHeaderTimeout: 5 * time.Second,
  ReadTimeout:       10 * time.Second,
  WriteTimeout:      10 * time.Second,
  IdleTimeout:       120 * time.Second,
}
log.Fatal(srv.ListenAndServe())

🐸 Библиотека Go для собеса

❓ Что означает гарантия «фиксеры не должны менять поведение вашей программы»

Это про автоматические исправления кода — фиксеры (например, go fix, gofmt, suggested fixes из go vet / analysis-фреймворка, или --fix в линтерах вроде golangci-lint). Гарантия говорит, что такой фикс меняет только форму кода, но не его поведение во время выполнения.

Под поведением тут понимается наблюдаемая семантика: что программа возвращает, какие у неё сайд-эффекты — запись в файл, вызовы по сети, вывод, — как идёт control flow, какие ошибки и паники она порождает. То есть на тех же входных данных до и после фикса программа должна давать тот же результат и те же эффекты. Трансформация behavior-preserving, семантически нейтральная.

Пример: фиксер может переписать устаревший API на новый, переставить импорты через goimports, отформатировать код — но не должен, скажем, изменить условие в if так, что поменяется ветвление.

И тут ключевой момент — формулировка «should not», а не «will not». Это заявленное свойство по дизайну, а не строгая гарантия на все случаи. В Go, где есть интерфейсы, рефлексия, горутины и гонки, всегда найдётся пограничный кейс, где формально эквивалентная замена всё же меняет смысл. Поэтому на практике фиксы обычно делят на safe и unsafe: safe можно катить массово, unsafe применяют осознанно.

🐸 Библиотека Go для собеса

❓ Нужно ли создавать новый http.Client на каждый запрос

Нет. Client и его Transport безопасны для конкурентного использования и держат пул TCP соединений. Новый клиент на каждый запрос убивает keep alive, каждый вызов будет заново устанавливать соединение вместе с TLS рукопожатием.

Правильно создать один клиент на приложение и задать ему тайм аут, потому что у http.DefaultClient его нет.

🐸 Библиотека Go для собеса

❓ Освободится ли память после bigSlice = bigSlice[:5]

Нет, не обязательно. Операция [:5] создаёт новый слайс-заголовок с длиной 5, но он по-прежнему указывает на тот же самый underlying array. Пока хотя бы один слайс ссылается на этот массив, сборщик мусора не может его освободить. То есть даже если нам нужны первые 5 байт, за спиной может «висеть» все 10 MB:

Дело в том, что срез — это лишь тройка из указателя на массив, длины и ёмкости. Урезание длины меняет только заголовок и никак не влияет на память под ним. Capacity нового слайса по-прежнему указывает на конец исходного массива, поэтому GC считает его достижимым.

Чтобы отдать большой массив сборщику, нужные данные копируют в новый, компактный слайс, а ссылку на исходный обнуляют:

smallCopy := make([]byte, len(smallSlice))
copy(smallCopy, smallSlice)
bigSlice = nil

Тот же эффект короче — через append в nil-слайс, который выделит свежий массив под реальный объём данных:

smallCopy := append([]byte(nil), smallSlice...)

🐸 Библиотека Go для собеса

❓ Как отличить отсутствующий ключ от нулевого значения в мапе

Через второй возвращаемый параметр при обращении к мапе — так называемый comma-ok. Обычное чтение v := m[key] всегда вернёт значение: если ключа нет, это будет нулевое значение типа (0 для чисел, "" для строк, nil для указателей).

А значит, по одному только v нельзя понять, лежал ли там реальный ноль или ключа просто не было:

m := map[string]int{"a": 0}

v := m["a"] // 0 — но ключ есть
v = m["b"]  // 0 — а ключа нет

Форма с двумя переменными решает это: второе значение — булев флаг, который равен true, только если ключ действительно присутствует в мапе. Именно на него и нужно смотреть, а не на само значение:

v, ok := m["a"]
if ok {
    // ключ есть, v — реальное значение (даже если это 0)
}

_, ok = m["b"] // ok == false, ключа нет

Отсюда типичный идиоматичный паттерн — проверка и использование в одном if:

if v, ok := m[key]; ok {
    // работаем с v
}

🐸 Библиотека Go для собеса

❓ Как узнать, что канал закрыт

Обычное v := <-ch из закрытого канала не заблокируется и не паникует, а сразу вернёт нулевое значение типа.

Поэтому по одному v нельзя отличить «пришёл реальный ноль» от «канал закрыт и пуст — ровно как с мапой:

v := <-ch // 0 — но это может быть и настоящее значение, и признак закрытия

Второй параметр решает вопрос: флаг ok равен true, пока из канала можно прочитать отправленное значение, и становится false, когда канал закрыт и в нём не осталось буферизованных данных.

Важно, что закрытый канал сначала отдаёт всё, что в него успели записать, и только потом начинает возвращать false:

v, ok := <-ch
if !ok {
    // канал закрыт и пуст
}

На практике за приёмом из канала обычно стоит range, который сам корректно завершается при закрытии — отдельная проверка ok не нужна:

for v := range ch {
    // выполняется, пока канал не закрыт и не пустой
}

❓Как узнать, сколько элементов лежит в канале

Функция len(ch) возвращает количество элементов, которые сейчас лежат в буфере канала. Функция cap(ch) возвращает вместимость буфера, то есть сколько элементов канал может хранить, не блокируя отправителя.

Пример с буферизированным каналом:

ch := make(chan int, 5)
ch <- 1
ch <- 2

fmt.Println(len(ch)) // 2
fmt.Println(cap(ch)) // 5

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

ch := make(chan int)

fmt.Println(len(ch)) // 0
fmt.Println(cap(ch)) // 0

Значение len(ch) это снимок состояния на конкретный момент. Пока вы читаете результат и что-то с ним делаете, другая горутина уже могла записать или забрать элемент.

🐸 Библиотека Go для собеса

❓ Как извлечь подстроку из строки

Строка в Go это неизменяемый срез байт. Поэтому подстрока берётся так же, как срез, но с одной оговоркой. Индексы считаются в байтах, а не в символах. На ASCII разницы не видно, на кириллице или эмодзи всё ломается.

Срез по байтам

s := "hello world"
fmt.Println(s[0:5]) // hello
fmt.Println(s[6:])  // world

Такой срез не копирует данные, он ссылается на тот же массив байт. Работает за O(1).

Теперь то же самое с кириллицей:

s := "привет"
fmt.Println(s[0:3]) // "пр"? нет, это "п" с хвостом

Каждая кириллическая буква в UTF-8 занимает два байта, так что s[0:3] разрежет символ пополам и вы получите битые данные.

Срез по символам

Если нужны именно символы, переводим строку в срез рун:

r := []rune("привет")
fmt.Println(string(r[0:3])) // при

Здесь уже есть аллокация и проход по всей строке, то есть O(n). Для длинных строк в горячем цикле это заметно.

🐸 Библиотека Go для собеса

❓ Как найти подстроку в строке

Задача звучит просто, но у неё три разных ответа. Нужно узнать, есть ли подстрока вообще. Нужно узнать, где она находится. Нужно достать то, что вокруг неё. Для каждого случая в пакете strings есть своя функция, и брать не ту это лишняя работа.

Просто проверить наличие

if strings.Contains(s, "error") {
    // подстрока есть
}


strings.Contains возвращает bool. Рядом живут strings.HasPrefix и strings.HasSuffix для начала и конца строки, они дешевле, потому что не сканируют всё подряд.

if strings.HasPrefix(path, "/api/") {
    ...
}

Ещё есть strings.ContainsAny, которая проверяет вхождение любого символа из набора, и strings.ContainsRune для одной руны.

Найти позицию

i := strings.Index(s, "role=")
if i == -1 {
    return errors.New("not found")
}


strings.Index возвращает байтовый индекс первого вхождения либо -1. Проверка на -1 обязательна, иначе получите панику при попытке сделать срез. strings.LastIndex ищет с конца. strings.IndexByte работает с одним байтом и заметно быстрее, если ищете, например, запятую.

Индекс байтовый, но подставлять его в срез безопасно. Совпадение подстроки всегда начинается на границе символа, потому что UTF-8 самосинхронизирующаяся кодировка.

Достать содержимое

Чаще всего индекс нужен не сам по себе, а чтобы отрезать кусок. Тогда strings.Cut короче и понятнее.

before, after, found := strings.Cut("key=value", "=")
if !found {
    return errors.New("bad format")
}
// before "key", after "value"

Это идиоматичный способ с Go 1.18. Он заменяет связку Index плюс два среза и не даёт ошибиться со смещением на длину разделителя.

🐸 Библиотека Go для собеса

❓ Как предотвратить XSS и SQL инъекции

Мы никогда не склеиваем запрос строкой. Всегда плейсхолдеры драйвера, значения уходят отдельно от текста запроса:

row := db.QueryRowContext(ctx, "SELECT id FROM users WHERE email = $1", email)

Имена таблиц и колонок так подставить нельзя, для них белый список допустимых значений:

var allowed = map[string]string{"created": "created_at", "email": "email"}
col, ok := allowed[r.URL.Query().Get("sort")]
if !ok {
    col = "created_at"
}
query := fmt.Sprintf("SELECT id FROM users ORDER BY %s DESC", col)

Дополнительно ограниченные права у пользователя базы, чтобы ошибка не стоила всей схемы.

XSS

Пользовательский текст не попадает в HTML напрямую. Рендерим через html/template, он экранирует с учётом контекста, то есть по разному внутри тега, атрибута, href и блока <script>. text/template не экранирует ничего, в веб хендлере его быть не должно.
Приводить ввод к template.HTML нельзя, это отключение защиты. Если пользователю нужна разметка, чистим санитайзером вроде bluemonday по белому списку тегов.

Для API хватает encoding/json, но заголовки обязательны, иначе браузер угадает тип и отрендерит ответ как страницу:

w.Header().Set("Content-Type", "application/json; charset=utf-8")
w.Header().Set("X-Content-Type-Options", "nosniff")

Сверху Content-Security-Policy и куки с HttpOnly, чтобы случайная дыра не привела к краже сессии.

🐸 Библиотека Go для собеса

❓ Как спроектировать пул воркеров для обработки задач из очереди. Сколько горутин запускать и от чего зависит это число

Базовая конструкция — один канал jobs как очередь и N воркеров, которые из него читают. Канал сам работает балансировщиком: свободный воркер забирает следующую задачу, вручную раздавать ничего не нужно. Для управления жизненным циклом добавляем context (отмена, таймаут, shutdown), sync.WaitGroup (дождаться завершения всех) и правило «кто пишет в канал, тот его и закрывает» — results закрываем только после wg.Wait(), иначе паника. Закрытие jobs — сигнал воркерам, что задачи кончились.

Сколько горутин — зависит от природы задачи. Для CPU-bound (вычисления, парсинг) смысла запускать больше горутин, чем ядер, нет: они будут драться за те же ядра и добавлять оверхед на переключение контекста. Ориентир — runtime.GOMAXPROCS(0). Для IO-bound (БД, HTTP, диск) горутина большую часть времени спит в ожидании ответа, поэтому воркеров имеет смысл сильно больше ядер — десятки, сотни. Но потолок здесь задаёт не CPU, а узкое место вниз по потоку: пул коннектов к БД, rate limit API, лимит дескрипторов. Запускать 500 воркеров при 20 коннектах к базе бессмысленно.

Грубая прикидка через закон Литтла: N ≈ ядра × (1 + время_ожидания / время_CPU). Плюс не забываем про память — горутина дешёвая (~2–8 КБ стека), но при сотнях тысяч воркеров плюс их буферы это уже гигабайты.

Правильный инженерный ответ: точное число не угадывается, а подбирается. Берём разумный старт (GOMAXPROCS для CPU, кратно больше для IO), вешаем метрики (p99-латентность, throughput, глубина очереди, загрузка CPU) и тюним под реальную нагрузку. Число воркеров — это параметр конфигурации, а не константа в коде. И отдельно важен backpressure: если продьюсер быстрее пула, нужно заранее решить — копить в буфере, блокировать продьюсера или дропать задачи, иначе очередь растёт до OOM.

🐸 Библиотека Go для собеса