limitexceededexception 并非统一的非受检异常，而是来源不同、继承各异的超限异常变体；需按 timelimit/filesize/自定义三类分源施策，优先配置防御而非被动捕获。
limitexceededexception 不是统一的“非受检异常”，它本质是受检异常的变体，但因框架拦截或静默处理，常被误判。防范关键不在盲目 catch，而在于分清来源、源头设防、按类施策。
先看清楚是哪一类超限
不同 LimitExceededException 来源不同，处理策略完全不同：
-
TimeLimitExceededException：来自 JNDI/LDAP 操作（如 NamingContext 查询超时），继承自
NamingException，属于受检异常变体。若调用链未声明 throws，编译不报错但运行可能中断——建议在远程目录服务模块中显式捕获，并做降级（如返回空结果、走缓存） -
FileSizeLimitExceededException（Spring 中常为
MaxUploadSizeExceededException）：由StandardServletMultipartResolver在 DispatcherServlet 前置阶段拦截，根本不会进入 Controller——业务层无需 try-catch，否则是冗余且无效的 -
自定义 LimitExceededException：必须严格按继承关系处理——若 extends
RuntimeException，属非受检，靠前置校验+熔断兜底；若 extendsException，则必须 throws 或 try-catch，否则编译失败
配置比捕获更可靠
对上传类超限，防御应在请求抵达业务逻辑前完成：
- 在
application.yml中明确配置：
spring.servlet.multipart.max-file-size: 50MB
spring.servlet.multipart.max-request-size: 50MB - 确保前端 JS 校验与后端配置一致（例如都限制 50MB），避免用户提交后才被拒绝
- 若用 Tomcat，还需检查
server.xml中 Connector 的maxPostSize（单位字节），设为52428800（50MB）或 -1（不限）
执行时限别等异常发生
TimeLimitExceededException 是被动信号，主动控制更稳妥：
- 避免依赖 JNDI 自带超时，改用
CompletableFuture.orTimeout(3, TimeUnit.SECONDS)包装远程调用 - 对数据库查询，优先使用 JDBC 的
setQueryTimeout()或 MyBatis 的timeout属性 - 对 HTTP 调用，用 OkHttp/Feign 的 connect/read timeout 配置，而非等待 NamingException 抛出
自定义超限要守规范
自己定义的 QPS 超限、缓存条目数超限等异常，务必注意继承路径：
- 若希望开发者必须处理（强契约），继承
Exception，并在方法签名中 throws - 若用于快速失败、熔断降级（如 Sentinel 限流抛出的 BlockException），应继承
RuntimeException - 禁止混用：不要让一个类既 extends Exception 又在文档里写“可不捕获”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
