В чем разница между interceptor и filter в Spring AOP

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

Понимаете ли вы, на каком уровне работает каждый механизм. В самой формулировке есть подвох: фильтр вообще не относится к Spring AOP, это часть Servlet API. Следом обычно спрашивают, куда вы положите проверку токена или логирование тела запроса и почему.

Как отвечать

Разведите три вещи, которые часто смешивают:

• Filter: интерфейс jakarta.servlet.Filter, работает в сервлет-контейнере до DispatcherServlet. Видит сырой HttpServletRequest, может обернуть запрос или ответ, прервать цепочку, не вызвав chain.doFilter(). Про контроллеры ничего не знает. В Spring Boot регистрируется как бин или через FilterRegistrationBean, порядок задаётся @Order;
• HandlerInterceptor: механизм Spring MVC, работает внутри DispatcherServlet, когда обработчик уже найден. Методы preHandle, postHandle, afterCompletion, в preHandle доступен HandlerMethod с аннотациями метода. Подключается через WebMvcConfigurer.addInterceptors() с шаблонами путей;
• AOP-перехват: @Around-совет или MethodInterceptor на прокси любого бина, не только веб-слоя. Так устроены @Transactional и @Cacheable.

Практическое правило: всё, что касается HTTP целиком (CORS, сжатие, correlation id, аутентификация), идёт в фильтр. Spring Security, кстати, построен именно как цепочка фильтров через DelegatingFilterProxy и FilterChainProxy. Логика, которой нужен контекст обработчика (аннотация на методе, путь из маппинга), идёт в интерсептор. Сквозная логика сервисного слоя, вне HTTP, в аспект.

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

Пытаются изменить ответ в postHandle для @RestController. При @ResponseBody и ResponseEntity ответ записан ещё до вызова postHandle, для этого есть ResponseBodyAdvice или фильтр.

Путают интерсептор MVC с AOP и говорят, что он «перехватывает вызовы сервисов». HandlerInterceptor видит только HTTP-обработчики.

Забывают про ограничения прокси: аспект не сработает при вызове метода из того же класса через this и на private-методах.