Какое максимальное ограничение на количество загружаемых файлов?

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

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

Как отвечать

Лимит задаёт продукт, и его берут из требований. Если в требованиях пусто, это уже находка: вопрос аналитику и дефект на документацию. Затем покажите, где лимиты живут технически:

• в браузере: <input type="file" multiple> сам количество не ограничивает, лимит пишет фронтенд. accept только фильтрует диалог выбора и ни от чего не защищает;
• на сервере и прокси: у PHP max_file_uploads по умолчанию 20, upload_max_filesize 2 МБ; у nginx client_max_body_size 1 МБ; в Spring Boot spring.servlet.multipart.max-file-size 1 МБ и max-request-size 10 МБ. В интерфейсе может стоять 50 файлов, а nginx оборвёт запрос раньше;
• в хранилище и бизнес-правилах: квота на пользователя, общий объём вложений у одной сущности.

Тест-дизайн:

• граничные значения: ноль файлов, один, ровно N, на единицу меньше и на единицу больше N, отдельно общий размер на границе;
• способы добавления: выбор пачкой, по одному, drag-and-drop, повторная загрузка после удаления части файлов;
• обход клиента: запрос через Postman или curl с N + 1 файлами. Если сервер его принял, лимит декоративный;
• поведение при превышении: отклоняется всё или принимаются первые N, понятно ли сообщение, какой код ответа. Для слишком большого тела это 413 Content Too Large, так он называется в RFC 9110;
• нагрузка: максимум файлов на медленной сети, таймауты, отмена посреди загрузки.

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

Называют число, «обычно 10» или «от 5 до 20», вместо вопроса о требованиях.

Проверяют лимит только в интерфейсе. Клиентская проверка обходится за минуту, настоящая защита стоит на сервере.

Забывают про частичный результат: из 12 файлов 10 загрузились, 2 нет, а пользователь видит общее «Ошибка» и не знает, какие файлы повторить.