Порядок middleware: почему он важен

r.Use(A) и следом r.Use(B) собирают луковицу: слой A оборачивает слой B, B оборачивает хендлер. Запрос входит в A, потом в B, доходит до хендлера — и выходит наоборот: сначала своё дописывает B, потом A. Первый r.Use — самый внешний слой, последний — самый внутренний, хендлер — самое нутро. В исходниках chi middleware цепочка собирается из среза слоёв и оборачивает каждый вызов маршрута целиком — механика r.Use из урока про цепочку middleware здесь та же, меняется только вопрос: не «как подключить», а «в каком порядке». Отсюда правило чтения чужого стека: сверху вниз — путь запроса, снизу вверх — путь ответа. Каждый слой видит всё, что внутри него: лог видит статусы всех внутренних слоёв, recovery ловит паники всех внутренних слоёв, таймер меряет всё, что происходит под ним. Порядок middleware в chi и есть ответ на вопрос «кто кого видит»: подняли слой выше — он ослеп, опустили ниже — ослепли все над ним.

Механика обоих слоёв видна в исходниках v5. Logger создаёт запись, оборачивает ResponseWriter обёрткой и пишет строку в defer — после next.ServeHTTP: в строке оказывается статус, который обёртка успела увидеть. Recoverer в defer ловит панику и вызывает WriteHeader(500) — на том ResponseWriter, который ему передали. Если Logger снаружи, пятисотой от Recoverer проходит через обёртку, и строка лога показывает честный 500. Если Logger внутри Recoverer, при раскрутке его defer срабатывает раньше recover-а: в обёртке на тот момент нет ни одной записи статуса, и в лог уходит 200 по умолчанию, пока клиент получает 500 мимо обёртки. chi фиксирует это требование прямо в доккомментарии Logger: «Logger should go before any other middleware that may change the response, such as middleware.Recoverer». Стек паники при этом Recoverer печатает через PrintPrettyStack в stderr — с Logger и без него, а вот строка запроса зависит от порядка. Правило шире одной пары: до Logger не ставят ни один слой, который сам пишет ответ, — из урока про встроенные middleware это Logger и Recoverer, дальше к списку добавятся Timeout и Throttle.

RequestID — первый содержательный слой стека. Logger собирает строку один раз, при завершении запроса, и в момент сборки читает GetReqID из контекста: идентификатор, положенный позже Logger-а, в строку не попадает — журнал останется без [id], и сшивать записи между службами будет нечем. RealIP ставится рядом и тоже до Logger: from-адрес в строке лога берётся из RemoteAddr в момент сборки, и слой должен переписать его на адрес клиента заранее — иначе в логе один и тот же прокси на каждую запись. Оба слоя ничего не пишут в ответ и не решают судьбу запроса: их работа — подготовить данные для всех, кто ниже. По этой же причине они почти не могут паниковать — и это не мелочь, а условие места в стеке, к которому вернёмся в красной врезке. Если балансировщик долбит /ping, слой Heartbeat ставят совсем первым: проба отвечает точкой и 200, не доходя ни до лога, ни до чего-либо ещё.

Preflight — OPTIONS-запрос, который браузер шлёт перед непростым запросом, и у него есть свойство, ломающее порядок слоёв: Authorization в нём нет. Браузер не может приложить токен, потому что ещё не получил согласие сервера, — токен появится только в настоящем запросе. Если authRequired стоит выше cors.Handler, preflight доходит до проверки токена, токена нет — 401, заголовков согласия в ответе тоже нет, и браузер бракует запрос сам: фронтенд лежит, сервер невиновен, в логах хендлеров пусто. Поэтому cors.Handler регистрируется раньше auth: на preflight он отвечает сам, сверив Origin с настройками, и до авторизации дело не доходит, а настоящие запросы идут дальше — к проверке токена уже только там, где браузер его реально приложил. Общее правило из этого случая: слой, который должен отвечать на запрос особым образом, ставится выше слоя, который отсекает запросы по общему признаку.

Дедлайн и лимит параллелизма включаются до дорогой работы — иначе они охраняют уже потраченные силы. Timeout из урока про предохранители кладёт контексту дедлайн: чем раньше слой в цепочке, тем больше работы покрыто таймером, поэтому его место — сразу после страховок и задолго до хендлеров. Throttle отказывает при перегрузке до авторизации и декодирования тела: толпа не должна тратить сервис на проверки, результат которых всё равно будет выброшен. Относительно Logger оба стоят после него — отказы должны попадать в строку лога с честным статусом: обёртка видит и 504 от Timeout, и отказ Throttle, который по исходникам v5.0.8 уходит как 429 Too Many Requests с опциональным Retry-After. И заметьте направление: предохранители — тоже слои, меняющие ответ, поэтому они внутри Logger-а. Всё, что пишет ответ, живёт под логом; всё, что только готовит данные, — над ним.