Middleware — бесплатный тест онлайн

Вопрос 1 из 30

В разделе «Обёртки handler» показан конкретный случай. Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package main
import("fmt";"net/http")
func trace(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){fmt.Println("before");next.ServeHTTP(w,r);fmt.Println("after")})}
func main(){}

Обработчик возвращает 405 для POST и допускает только GET. GET можно повторить после временной сетевой ошибки, а POST без ключа идемпотентности может создать дубль. Первый вызов `Write` неявно отправляет статус 200, поэтому поздний `WriteHeader(500)` уже не меняет ответ. Сообщение `before` появляется до обработчика, а `after` — после его возврата. При отмене контекста ожидающий сетевой запрос завершается ошибкой, связанной с контекстом.

Вопрос 2 из 30

Команда проверяет решение по теме «Обёртки handler». Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("fmt";"net/http")
func trace(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){fmt.Println("before");next.ServeHTTP(w,r);fmt.Println("after")})}
func main(){}

Создавать запрос с контекстом, проверять ошибку `Do`, статус и ограниченно читать тело, затем закрывать его. Создать долгоживущий клиент с настроенным транспортом и не менять его поля конкурентно после начала работы. Держать middleware узким: одна ответственность, явный контракт и обязательный вызов `next` только на разрешённом пути. Ограничить число попыток, использовать экспоненциальную задержку с разбросом и учитывать `Retry-After`. Нормализовать пути осторожно, явно ограничивать методы и централизовать декодирование параметров.

Вопрос 3 из 30

Перед публикацией кода по теме «Обёртки handler» нужно уточнить контракт. Какое свойство конструкции определяет её поведение?

// Определите правило Go, которое объясняет результат.
package main
import("fmt";"net/http")
func trace(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){fmt.Println("before");next.ServeHTTP(w,r);fmt.Println("after")})}
func main(){}

`http.NewRequestWithContext` связывает запрос с отменой; тело должно быть закрыто после успешного `Do`, даже при неожиданном статусе. Повтор безопасен только при идемпотентной операции или наличии протокола идемпотентности и возможности заново создать тело. Middleware принимает следующий `http.Handler` и возвращает новый, выполняя работу до и после `next.ServeHTTP`. `http.Transport` и `http.Client` безопасны для конкурентного повторного использования; новый клиент на каждый запрос разрушает пул соединений. Маршрут должен однозначно связывать метод, путь и параметры; проверка метода остаётся частью контракта обработчика.

Вопрос 4 из 30

В рабочем примере по теме «Обёртки handler» важно отделить гарантию от догадки. Что стоит проверить до переноса решения в общий компонент?

Повторный вызов `next` выполнит обработчик дважды и может дважды изменить состояние. Нельзя автоматически повторять запрос после частичной отправки тела, если сервер мог уже применить операцию. Не закрытое или не дочитанное тело может помешать повторному использованию соединения. После частично записанного ответа нельзя надёжно заменить его на чистый JSON ошибки. Ненулевой `Response` иногда может сопровождать ошибку только в особых случаях перенаправления; обычный код не должен предполагать тело при ошибке.

Вопрос 5 из 30

Фрагмент относится к теме «Обёртки handler». Как точнее всего описать пользу и цену этого решения?

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

Вопрос 6 из 30

Команда проверяет решение по теме «Логи». К какому результату приводит показанная конструкция?

// Фрагмент для трассировки.
package main
import "net/http"
type capture struct{ http.ResponseWriter; status int }
func(c *capture)WriteHeader(n int){c.status=n;c.ResponseWriter.WriteHeader(n)}
func main(){}

Один клиент обслуживает много запросов и повторно использует keep-alive соединения через транспорт. Первый вызов `Write` неявно отправляет статус 200, поэтому поздний `WriteHeader(500)` уже не меняет ответ. Обёртка фиксирует 204, даже если обработчик не пишет тело. Обработчик возвращает 405 для POST и допускает только GET. При отмене контекста ожидающий сетевой запрос завершается ошибкой, связанной с контекстом.

Вопрос 7 из 30

Перед публикацией кода по теме «Логи» нужно уточнить контракт. Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "net/http"
type capture struct{ http.ResponseWriter; status int }
func(c *capture)WriteHeader(n int){c.status=n;c.ResponseWriter.WriteHeader(n)}
func main(){}

Сохранять статус, длительность, метод и нормализованный маршрут, не записывая секретные заголовки и полное тело. Создавать запрос с контекстом, проверять ошибку `Do`, статус и ограниченно читать тело, затем закрывать его. Создать долгоживущий клиент с настроенным транспортом и не менять его поля конкурентно после начала работы. Проверять ошибки до записи тела, устанавливать заголовки заранее и возвращаться после отправки ошибки. Ограничить число попыток, использовать экспоненциальную задержку с разбросом и учитывать `Retry-After`.

Вопрос 8 из 30

В рабочем примере по теме «Логи» важно отделить гарантию от догадки. На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package main
import "net/http"
type capture struct{ http.ResponseWriter; status int }
func(c *capture)WriteHeader(n int){c.status=n;c.ResponseWriter.WriteHeader(n)}
func main(){}

`http.Handler` получает `ResponseWriter` и `Request`; заголовок статуса следует записать до тела. `http.Transport` и `http.Client` безопасны для конкурентного повторного использования; новый клиент на каждый запрос разрушает пул соединений. Маршрут должен однозначно связывать метод, путь и параметры; проверка метода остаётся частью контракта обработчика. Журнал запроса должен содержать структурированные поля и итоговый статус; для этого ResponseWriter оборачивают, сохраняя вызов `WriteHeader`. `http.NewRequestWithContext` связывает запрос с отменой; тело должно быть закрыто после успешного `Do`, даже при неожиданном статусе.

Вопрос 9 из 30

Фрагмент относится к теме «Логи». Какое ограничение опаснее всего пропустить?

Не закрытое или не дочитанное тело может помешать повторному использованию соединения. Ненулевой `Response` иногда может сопровождать ошибку только в особых случаях перенаправления; обычный код не должен предполагать тело при ошибке. Нельзя автоматически повторять запрос после частичной отправки тела, если сервер мог уже применить операцию. Простая обёртка может потерять дополнительные интерфейсы `Flusher`, `Hijacker` или `Pusher`, необходимые некоторым обработчикам. Нельзя считать путь безопасным файловым именем без очистки и ограничения корневым каталогом.

Вопрос 10 из 30

На ревью разбирают тему «Логи». Какой вывод о сопровождении решения наиболее взвешенный?

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

Вопрос 11 из 30

Перед публикацией кода по теме «Аутентификация» нужно уточнить контракт. Как завершится показанный фрагмент при указанных входных данных?

// Фрагмент для трассировки.
package main
import "net/http"
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){if r.Header.Get("Authorization")!="Bearer ok"{http.Error(w,"unauthorized",401);return};next.ServeHTTP(w,r)})}
func main(){}

Один клиент обслуживает много запросов и повторно использует keep-alive соединения через транспорт. Первый вызов `Write` неявно отправляет статус 200, поэтому поздний `WriteHeader(500)` уже не меняет ответ. При неверном токене цепочка завершается 401 и `next` не вызывается. При отмене контекста ожидающий сетевой запрос завершается ошибкой, связанной с контекстом. Обработчик возвращает 405 для POST и допускает только GET.

Вопрос 12 из 30

В рабочем примере по теме «Аутентификация» важно отделить гарантию от догадки. Что здесь следует изменить прежде всего?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "net/http"
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){if r.Header.Get("Authorization")!="Bearer ok"{http.Error(w,"unauthorized",401);return};next.ServeHTTP(w,r)})}
func main(){}

Разделять аутентификацию и авторизацию, сравнивать секреты безопасным способом и ограничивать время проверки. Создавать запрос с контекстом, проверять ошибку `Do`, статус и ограниченно читать тело, затем закрывать его. Нормализовать пути осторожно, явно ограничивать методы и централизовать декодирование параметров. Ограничить число попыток, использовать экспоненциальную задержку с разбросом и учитывать `Retry-After`. Проверять ошибки до записи тела, устанавливать заголовки заранее и возвращаться после отправки ошибки.

Вопрос 13 из 30

Фрагмент относится к теме «Аутентификация». Какое правило отделяет верный разбор от правдоподобной догадки?

// Определите правило Go, которое объясняет результат.
package main
import "net/http"
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){if r.Header.Get("Authorization")!="Bearer ok"{http.Error(w,"unauthorized",401);return};next.ServeHTTP(w,r)})}
func main(){}

Middleware аутентификации проверяет учётные данные до вызова бизнес-обработчика и передаёт проверенную личность в типизированном контексте. Повтор безопасен только при идемпотентной операции или наличии протокола идемпотентности и возможности заново создать тело. `http.NewRequestWithContext` связывает запрос с отменой; тело должно быть закрыто после успешного `Do`, даже при неожиданном статусе. `http.Transport` и `http.Client` безопасны для конкурентного повторного использования; новый клиент на каждый запрос разрушает пул соединений. Маршрут должен однозначно связывать метод, путь и параметры; проверка метода остаётся частью контракта обработчика.

Вопрос 14 из 30

На ревью разбирают тему «Аутентификация». Какой крайний случай обязан попасть в тесты?

Наличие токена ещё не означает право на конкретный ресурс; это отдельная проверка политики. Нельзя автоматически повторять запрос после частичной отправки тела, если сервер мог уже применить операцию. После частично записанного ответа нельзя надёжно заменить его на чистый JSON ошибки. Ненулевой `Response` иногда может сопровождать ошибку только в особых случаях перенаправления; обычный код не должен предполагать тело при ошибке. Не закрытое или не дочитанное тело может помешать повторному использованию соединения.

Вопрос 15 из 30

В разделе «Аутентификация» показан конкретный случай. Какой выбор лучше отражает баланс простоты и контроля?

Стандартный мультиплексор прост и быстр, а сторонний маршрутизатор оправдан сложными параметрами и общей политикой. Централизация уменьшает дублирование, но исключения маршрутов должны быть явными и тестируемыми. Пул снижает задержку и число рукопожатий, но требует лимитов простаивающих соединений и контроля адресов назначения. Явный запрос позволяет заголовки и контекст, но обёртка вокруг клиента полезна для единой политики ошибок и метрик. Буферизация позволяет решить статус до отправки, но увеличивает память и задержку потоковых ответов.

Вопрос 16 из 30

В рабочем примере по теме «Порядок цепочки» важно отделить гарантию от догадки. Как изменится состояние программы после этого фрагмента?

// Фрагмент для трассировки.
package main
import "net/http"
func chain(h http.Handler)http.Handler{ return recoverMW(logMW(auth(h))) }
func recoverMW(h http.Handler)http.Handler{return h};func logMW(h http.Handler)http.Handler{return h};func auth(h http.Handler)http.Handler{return h}
func main(){}

GET можно повторить после временной сетевой ошибки, а POST без ключа идемпотентности может создать дубль. Первый вызов `Write` неявно отправляет статус 200, поэтому поздний `WriteHeader(500)` уже не меняет ответ. Один клиент обслуживает много запросов и повторно использует keep-alive соединения через транспорт. `recover(log(auth(h)))` позволяет внешнему восстановлению поймать панику из всех внутренних слоёв. Обработчик возвращает 405 для POST и допускает только GET.

Вопрос 17 из 30

Фрагмент относится к теме «Порядок цепочки». Какое замечание на ревью будет наиболее точным?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import "net/http"
func chain(h http.Handler)http.Handler{ return recoverMW(logMW(auth(h))) }
func recoverMW(h http.Handler)http.Handler{return h};func logMW(h http.Handler)http.Handler{return h};func auth(h http.Handler)http.Handler{return h}
func main(){}

Создать долгоживущий клиент с настроенным транспортом и не менять его поля конкурентно после начала работы. Нормализовать пути осторожно, явно ограничивать методы и централизовать декодирование параметров. Зафиксировать порядок в одной функции сборки и тестами проверять отказ на каждом этапе. Создавать запрос с контекстом, проверять ошибку `Do`, статус и ограниченно читать тело, затем закрывать его. Проверять ошибки до записи тела, устанавливать заголовки заранее и возвращаться после отправки ошибки.

Вопрос 18 из 30

На ревью разбирают тему «Порядок цепочки». Какое правило важнее случайных деталей конкретного запуска?

// Определите правило Go, которое объясняет результат.
package main
import "net/http"
func chain(h http.Handler)http.Handler{ return recoverMW(logMW(auth(h))) }
func recoverMW(h http.Handler)http.Handler{return h};func logMW(h http.Handler)http.Handler{return h};func auth(h http.Handler)http.Handler{return h}
func main(){}

Порядок обёрток определяет, какие события видит каждый слой и сможет ли он обработать панику или записать итоговый статус. `http.Transport` и `http.Client` безопасны для конкурентного повторного использования; новый клиент на каждый запрос разрушает пул соединений. Маршрут должен однозначно связывать метод, путь и параметры; проверка метода остаётся частью контракта обработчика. `http.NewRequestWithContext` связывает запрос с отменой; тело должно быть закрыто после успешного `Do`, даже при неожиданном статусе. `http.Handler` получает `ResponseWriter` и `Request`; заголовок статуса следует записать до тела.

Вопрос 19 из 30

В разделе «Порядок цепочки» показан конкретный случай. Где корректный фрагмент легко становится ошибочным?

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

Вопрос 20 из 30

Команда проверяет решение по теме «Порядок цепочки». Что учитывать при выборе этого приёма для публичного API?

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

Вопрос 21 из 30

Фрагмент относится к теме «Тестирование и наблюдаемость» в тесте «Middleware». Какой результат даст этот код на поддерживаемой реализации Go?

// Фрагмент для трассировки.
package sample
import("net/http";"net/http/httptest";"testing")
func TestAuthStops(t *testing.T){called:=0;next:=http.HandlerFunc(func(http.ResponseWriter,*http.Request){called++});r:=httptest.NewRequest("GET","/",nil);w:=httptest.NewRecorder();auth(next).ServeHTTP(w,r);if called!=0||w.Code!=401{t.Fatal(called,w.Code)}}
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){http.Error(w,"no",401)})}

Специальный `Reader` с одним байтом за вызов проверяет, что функция не рассчитывает на заполнение буфера сразу. Счётчик заглушки доказывает, что при 401 внутренний обработчик не был вызван. `benchstat` сравнивает несколько выборок и показывает статистическую устойчивость различий. Точный итог счётчика и чистый `-race` проверяют разные стороны: смысл и отсутствие обнаруженной гонки. Тест считается успешным только если вызов действительно вызвал ожидаемую панику; отсутствие паники — отдельная ошибка теста.

Вопрос 22 из 30

На ревью разбирают тему «Тестирование и наблюдаемость» в тесте «Middleware». Что нужно поменять, чтобы граничный случай не превратился в сбой?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package sample
import("net/http";"net/http/httptest";"testing")
func TestAuthStops(t *testing.T){called:=0;next:=http.HandlerFunc(func(http.ResponseWriter,*http.Request){called++});r:=httptest.NewRequest("GET","/",nil);w:=httptest.NewRecorder();auth(next).ServeHTTP(w,r);if called!=0||w.Code!=401{t.Fatal(called,w.Code)}}
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){http.Error(w,"no",401)})}

Использовать `iotest` и собственные маленькие заглушки, измерять число байтов и длительность без записи содержимого секретных потоков. Проверять заголовки, контекст, статус, паники и дополнительные интерфейсы ResponseWriter. Записывать метод, хост, статус, длительность и категорию ошибки, не превращая URL с идентификаторами в метки высокой кардинальности. Хранить репрезентативные старые документы в `testdata`, проверять ограничения размера и не журналировать полный чувствительный JSON. Выносить проверку паники в небольшую функцию и добавлять `debug.Stack()` в журнал на эксплуатационной границе.

Вопрос 23 из 30

В разделе «Тестирование и наблюдаемость» показан конкретный случай в тесте «Middleware». Какое свойство конструкции определяет её поведение?

// Определите правило Go, которое объясняет результат.
package sample
import("net/http";"net/http/httptest";"testing")
func TestAuthStops(t *testing.T){called:=0;next:=http.HandlerFunc(func(http.ResponseWriter,*http.Request){called++});r:=httptest.NewRequest("GET","/",nil);w:=httptest.NewRecorder();auth(next).ServeHTTP(w,r);if called!=0||w.Code!=401{t.Fatal(called,w.Code)}}
func auth(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){http.Error(w,"no",401)})}

Конвейер тестируют на пустом входе, ранней отмене, медленном потребителе и закрытии всех выходов; отдельно считают активные работники. Обобщённый алгоритм тестируют представителями разных ветвей ограничения и именованными типами, а не только `int`. Синхронизацию проверяют под `-race`, повторными прогонами и инвариантами результата, а не только отсутствием паники. Обработчики удобно тестировать `httptest.NewRequest` и `ResponseRecorder`, отдельно проверяя статус, заголовки и тело. Каждый middleware тестируют отдельно и в реальном порядке цепочки, включая отсутствие вызова `next`.

Вопрос 24 из 30

Команда проверяет решение по теме «Тестирование и наблюдаемость» в тесте «Middleware». Что стоит проверить до переноса решения в общий компонент?

Тест только конечного тела не обнаружит двойной вызов `next` или потерю `Flusher`. Проверка только текста ошибки может сломаться; причины следует распознавать через значения пакета `context` и `errors.Is`. Тест только с `bytes.Buffer` слишком дружелюбен и может не выявить ошибочную обработку частичного чтения. Можно убрать отчёт гонки одной блокировкой, но сохранить логическую потерю обновления в другом месте. Тесты только внутри пакета могут случайно зависеть от деталей, недоступных реальному пользователю.

Вопрос 25 из 30

Перед публикацией кода по теме «Тестирование и наблюдаемость» нужно уточнить контракт в тесте «Middleware». Как точнее всего описать пользу и цену этого решения?

Подменный транспорт даёт точный тест политики, а `httptest.Server` лучше проверяет настоящий HTTP-обмен. Изолированный тест локализует дефект, а тест цепочки ловит ошибки порядка и взаимодействия слоёв. Виртуальное время делает тесты быстрыми, но требует дополнительной абстракции и проверки её соответствия реальным таймерам. Случайный порядок ловит зависимость тестов, но найденную нестабильность нужно устранить, а не просто повторять до успеха. Золотой файл хорошо ловит изменение формата, но требует осознанного пересмотра, а не автоматического обновления.

Вопрос 26 из 30

На ревью разбирают тему «Конкурентность и эксплуатация». К какому результату приводит показанная конструкция?

// Фрагмент для трассировки.
package main
import("net/http";"sync/atomic")
var requests atomic.Uint64
func count(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){requests.Add(1);next.ServeHTTP(w,r)})}
func main(){}

Атомарный счётчик корректно считает входы без общей блокировки большой критической секции. Запись в общую карту без мьютекса из двух запросов создаёт гонку и может вызвать аварийное сообщение runtime. Высокое время блокировки указывает, что горутины ждут канал или мьютекс, хотя CPU может быть свободен. Маршрут `/users/:id` используется как метка вместо фактического `/users/918273`. Семафор не позволяет одновременно выполнять больше двадцати внешних запросов.

Вопрос 27 из 30

В разделе «Конкурентность и эксплуатация» показан конкретный случай. Какую правку стоит предложить на ревью, сохранив назначение кода?

// Фрагмент из ревью: требуется выбрать безопасную правку.
package main
import("net/http";"sync/atomic")
var requests atomic.Uint64
func count(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){requests.Add(1);next.ServeHTTP(w,r)})}
func main(){}

Назначать уникальные порты через прослушивание `:0`, не менять глобальное окружение параллельно и закрывать серверы через Cleanup. Ограничивать параллелизм, задавать контекст, отслеживать WaitCount/WaitDuration и избегать запросов N+1. Ограничивать кардинальность меток, контролировать очередь лимитера и не удерживать глобальную блокировку во время `next`. Снимать профиль блокировок под нагрузкой, проверять длины очередей и не включать дорогой сбор постоянно без оценки. Считать запросы, категории ошибок, гистограмму задержки, очередь и ресурсы зависимостей; связывать с трассировкой через exemplar.

Вопрос 28 из 30

Команда проверяет решение по теме «Конкурентность и эксплуатация». На какой контракт языка или стандартной библиотеки здесь нужно опереться?

// Определите правило Go, которое объясняет результат.
package main
import("net/http";"sync/atomic")
var requests atomic.Uint64
func count(next http.Handler)http.Handler{return http.HandlerFunc(func(w http.ResponseWriter,r *http.Request){requests.Add(1);next.ServeHTTP(w,r)})}
func main(){}

Пакет должен явно заявлять конкурентную безопасность и владение фоновой работой; `Close` обязан иметь понятный повторный контракт. Конфигурацию читают и валидируют до запуска рабочих горутин; секреты отделяют от безопасных параметров и не печатают целиком. Ограничение параллелизма и пула соединений защищает и клиент, и удалённый сервис от лавины запросов. Middleware выполняется конкурентно для запросов; изменяемые счётчики, кеши и ограничители должны быть безопасны. Метрики должны отвечать на вопросы о трафике, ошибках, задержке и насыщении; метки обязаны иметь ограниченную кардинальность.

Вопрос 29 из 30

Перед публикацией кода по теме «Конкурентность и эксплуатация» нужно уточнить контракт. Какое ограничение опаснее всего пропустить?

Бесконечный обработчик или зависшая фоновая горутина могут пережить срок `Shutdown`. Нулевые серверные таймауты оставляют процесс уязвимым для очень медленных клиентов. Мьютекс, удерживаемый вокруг `next`, последовательно обработает весь сервер и может привести к взаимной блокировке. Увеличение числа горутин при одном глобальном мьютексе часто лишь увеличивает очередь. Два последовательных этапа с собственными большими буферами могут скрыть минуты накопленной задержки.

Вопрос 30 из 30

В рабочем примере по теме «Конкурентность и эксплуатация» важно отделить гарантию от догадки. Какой вывод о сопровождении решения наиболее взвешенный?

Жёсткие лимиты защищают ёмкость, но должны учитывать законные большие загрузки и потоковые ответы. Автоматический фон удобен пользователю, но увеличивает скрытые ресурсы и усложняет завершение процесса. Параллельность сокращает время CI, но внешняя база или лимит CPU могут стать общим узким местом. Глобальный лимит защищает процесс, но справедливость между маршрутами может потребовать отдельных квот. Длинный льготный срок сохраняет запросы, но замедляет выпуск и может удерживать старую версию слишком долго.