Что такое MultipartResolver и для чего он используется в Spring

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

Знаете ли вы, как запрос с файлом превращается в аргумент метода контроллера, и понимаете ли, что в этой цепочке настраивается, а что нет. Вопрос любят потому, что ответ сразу показывает, работал ли человек с загрузкой файлов или пересказывает старую статью.

Как отвечать

MultipartResolver это интерфейс, которым диспетчер решает две задачи: определить, что запрос составной, и обернуть его так, чтобы части стали доступны как файлы и параметры. Дальше связывание работает как обычно:

@PostMapping("/upload")
public String upload(@RequestParam("file") MultipartFile file) { ... }

Что стоит проговорить:

• Основная реализация сегодня та, что опирается на стандартный API сервлетов. Вариант поверх Apache Commons FileUpload объявлен устаревшим и убран из свежих веток фреймворка, предлагать его как основной не стоит.
• Бин ищется по фиксированному имени multipartResolver. Назовёте иначе, резолвер молча не подключится, а запрос придёт без файла.
• В Spring Boot резолвер поднимает автоконфигурация, а ограничения размера задаются свойствами приложения. Стандартная реализация сама размер не режет, это делает контейнер.
• Для смеси JSON и файла в одной форме берут аннотацию части запроса, а не обычный параметр.

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

Рассказывают про конфигурацию поверх Commons FileUpload как про текущую практику. На новом стеке такой бин просто не соберётся, и это заметный сигнал, что опыт остался на старых версиях.

Объявляют свой бин в приложении на Boot и ломают автоконфигурацию: заданные свойства перестают действовать, а причину искать тяжело, потому что ошибки не возникает, файл просто приходит не так, как ожидали.

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