Как программа определяет URL для выполнения запросов по списку

Что проверяют

Умеете ли вы надёжно превращать входные данные в корректные адреса и отправлять по ним запросы стандартными средствами Go. Обычно это часть задачи «обойти список URL», и следом спрашивают про валидацию, таймауты и параллельную обработку.

Как отвечать

Опишите путь адреса от входа до запроса:

• источник: список приходит срезом, файлом (читается построчно через bufio.Scanner) или из канала от продюсера. Пустые строки и комментарии отбрасываются сразу;
• разбор: url.Parse очень снисходителен. Строка example.com разберётся с пустыми схемой и хостом и целиком попадёт в путь. Поэтому после разбора проверяем, что u.Scheme равна http или https, а u.Host не пустой. url.ParseRequestURI строже, но эту проверку не заменяет;
• сборка из частей: базовый адрес плюс путь через url.JoinPath (есть с Go 1.19) или ResolveReference для относительных ссылок. Параметры через url.Values и Encode(), который сам экранирует значения;
• запрос: http.NewRequestWithContext(ctx, http.MethodGet, u.String(), nil) и один общий http.Client с заданным Timeout на всю программу, чтобы соединения переиспользовались;
• распределение: адреса отправляются в канал, из которого читает фиксированное число воркеров. Так ограничивается параллелизм и нагрузка на чужие серверы.

Из-за одного невалидного адреса программа не должна падать: его логируют с номером строки и идут дальше.

Где спотыкаются

Склеивают URL конкатенацией строк. Пробел, амперсанд или кириллица в параметре ломают запрос, нужны url.Values либо url.QueryEscape и url.PathEscape.

Ожидают, что Encode() сохранит порядок параметров. Он сортирует их по ключу, и page=1&limit=10 превратится в limit=10&page=1. Серверу обычно всё равно, а вот тест со сравнением строк упадёт.

Используют http.Get с клиентом по умолчанию, у которого нет таймаута, и забывают defer resp.Body.Close(). Один зависший хост держит воркер вечно, а незакрытые тела не дают переиспользовать соединения.