接口层注入防御需构建“前置过滤+异常兜底+行为识别”三层防线，异常子类仅作绕过验证的隐式攻击线索，条件验证器须主动扫描注入指纹并记录警告，catch块专注聚合响应与风控降级。
接口层拦截黑客注入，不能只靠 try-catch 捕获异常子类，也不能仅依赖条件验证器——二者需协同设计，形成“前置过滤 + 异常兜底 + 行为识别”的三层防线。核心不是等异常发生再处理，而是把异常捕获作为最后校验手段，用于发现绕过验证的隐式攻击行为。
明确异常子类在注入防御中的真实角色
运行时异常（如 SQLException、IllegalArgumentException、NumberFormatException）本身不是攻击信号，但它们的**非预期触发模式**可能是注入线索：
- 正常业务中极少抛出
SQLException，若在参数解析后、SQL执行前就出现，大概率是恶意 SQL 片段触发了驱动层语法检查 -
NumberFormatException在整型 ID 参数中高频出现，且伴随非常规值（如1 OR 1=1、id; DROP TABLE users），属于典型数字型注入试探 -
JsonProcessingException出现在 JSON 反序列化阶段，若错误位置固定在字段名或值开头（如 `"user":"admin'--"`），提示 JSON 注入尝试
条件验证器必须覆盖常见注入特征，而非仅做格式校验
标准注解（如 [Range]、[StringLength]）无法识别语义攻击。应使用可编程验证器主动扫描注入指纹：
- 对字符串参数启用轻量正则检测：
.*(--|;|/\*|\bUNION\b|\bSELECT\b|\bINSERT\b|\bDROP\b).*（注意：不用于阻断，仅打标供后续分析） - 对数字/布尔参数强制白名单转换：拒绝任何含非数字字符的输入，不尝试
Integer.parseInt()后捕获异常来“试探” - 对 JSON 字段启用结构校验：用
ObjectMapper的DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES防止额外字段注入 - 记录所有触发验证警告的请求（IP、UA、参数快照），不立即拒绝，避免暴露防御逻辑
在 catch 块中做攻击行为聚合与响应降级
当验证器未拦截、但运行时异常仍被触发时，说明攻击已穿透前置层。此时 catch 块应放弃“修复”，专注三件事：
- 统一记录异常上下文：包括原始请求路径、参数哈希、异常类型、堆栈首帧方法名（避免泄露内部类）
- 返回标准化响应：HTTP 400 或 422，响应体仅含通用提示（如
"Invalid input"），不带异常消息 - 触发实时风控动作：对同一 IP 5 分钟内触发 3 次同类异常，自动加入临时黑名单（内存缓存，TTL=15min）
关键避坑点
以下做法会削弱防御效果甚至引入新风险：
- 在 catch 中拼接异常消息返回前端 → 泄露数据库版本、表结构、框架路径
- 用
Exception大类捕获并统一处理 → 掩盖真实攻击类型，丢失研判依据 - 验证器里调用
executeQuery()测试 SQL 是否合法 → 直接执行恶意语句 - 将异常日志写入公开可读文件 → 成为攻击者探测系统状态的入口
