java中无统一sizelimitexception，常见的是spring的maxuploadsizeexceededexception、tomcat的sizelimitexceededexception等，本质为受检或非受检异常变体，应通过配置拦截而非业务层try-catch。
Java中没有统一的 SizeLimitException 类，它并非 JDK 或 Spring 官方标准异常；实际开发中遇到的所谓“SizeLimitException”，多指 FileSizeLimitExceededException（Spring）、SizeLimitExceededException（Tomcat 底层）或 MaxUploadSizeExceededException 等具体异常——它们**本质是受检异常的变体，但常被框架提前拦截，不进入业务代码，因此无需、也不应盲目 try-catch**。
认清真实异常类型和传播路径
不同“超限”异常来源不同，处理逻辑截然不同：
-
Spring 的 MaxUploadSizeExceededException：由
StandardServletMultipartResolver在 DispatcherServlet 前置阶段捕获并包装，根本不会到达 Controller 层。业务方法里写try-catch(MaxUploadSizeExceededException)是无效且冗余的 -
Tomcat 底层的 SizeLimitExceededException：属于
org.apache.tomcat.util.http.fileupload.impl包，是RuntimeException的子类（非受检），但它在 Spring MVC 流程中已被封装为上层异常，开发者通常接触不到原始形态 -
自定义 SizeLimitException：若你自行定义了该类，必须明确继承关系——继承
RuntimeException则为非受检，需靠前置校验拦截；继承Exception则为受检，编译器会强制要求throws或try-catch
配置拦截优于代码捕获
这类异常是系统配置不足的信号，不是业务逻辑分支。应在请求进入控制器前完成限制：
- 在
application.yml中设置明确值（不要依赖默认 1MB）：
spring:
servlet:
multipart:
max-file-size: 50MB
max-request-size: 50MB - 若用 Tomcat 嵌入式容器，还需检查
server.xml中Connector的maxPostSize（单位字节），设为52428800（50MB）或-1（不限） - 前端同步校验：上传前读取
File.size，超过阈值直接提示，避免无谓请求
全局统一响应，不依赖异常穿透
即使配置生效，某些边界情况（如 multipart 解析失败、IO 中断）仍可能抛出未被捕获的运行时异常。应通过全局处理器兜底：
- 使用
@ControllerAdvice拦截MaxUploadSizeExceededException和RuntimeException子类 - 返回结构化 JSON，含
code（如"UPLOAD_SIZE_EXCEEDED"）、message（脱敏友好文案）、traceId - 避免返回原始堆栈或
e.getMessage()，防止敏感信息泄露
流式上传场景下的主动终止
对非 multipart 场景（如 application/octet-stream），需在读取过程中实时判断：
- 用
HttpServletRequest.getInputStream()逐块读取，累加字节数 - 一旦超过阈值（如 50MB），立即调用
response.sendError(413, "文件过大")并 return - 避免将全部数据读入内存或临时文件，防止 OOM 或磁盘耗尽
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
