В чем разница между фильтрами и интерсепторами по бизнес-логике и порядку вызова
Что проверяют
Знаете ли вы, где в Spring-приложении живёт каждый механизм: фильтр принадлежит контейнеру сервлетов, а HandlerInterceptor работает внутри Spring MVC. Следом обычно просят расписать порядок вызовов для двух фильтров и двух интерсепторов или спрашивают, куда девается исключение из фильтра.
Как отвечать
Filter(jakarta.servlet.Filterв Spring Boot 3): оборачивает запрос целиком, ещё доDispatcherServlet. Видит сыройHttpServletRequest, может подменить запрос или ответ обёрткой и прервать цепочку, не вызвавchain.doFilter(). Порядок задают@OrderилиFilterRegistrationBean.setOrder(). На фильтрах построен Spring Security;HandlerInterceptor: его вызываетDispatcherServletпосле выбора обработчика, поэтому он знает, какой метод контроллера сработает, и читает его аннотации черезHandlerMethod. Точки:preHandle(вернулfalse, контроллер не вызовется),postHandle(после контроллера, до рендера),afterCompletion(всегда, еслиpreHandleвернулtrue). Регистрируется вWebMvcConfigurer.addInterceptors().
Порядок: фильтр 1, фильтр 2, DispatcherServlet, preHandle интерсепторов по порядку, контроллер, postHandle в обратном порядке, afterCompletion тоже в обратном, затем выход через фильтры.
Бизнес-логики нет ни там, ни там, оба механизма для сквозных задач. Фильтру достаётся то, что не зависит от контроллера: CORS, трассировка, сжатие, аутентификация. Интерсептору то, что зависит от обработчика: проверка прав по аннотации метода, локаль, метрики по эндпоинтам. Транзакции делаются AOP-прокси через @Transactional, а не интерсепторами MVC.
Где спотыкаются
Пытаются поменять тело ответа в postHandle для @ResponseBody. К этому моменту ответ уже записан, нужен ResponseBodyAdvice или фильтр.
Ждут, что @ControllerAdvice поймает исключение из фильтра. Он работает только внутри DispatcherServlet, ошибку фильтра обрабатывают в самом фильтре.
Путают HandlerInterceptor с AOP и CDI-интерсепторами (@AroundInvoke) и отвечают про перехват методов сервисов.