Filter不能直接转义SQL字符，因其仅拦截HTTP请求响应而不处理SQL；SQL注入防护应在DAO层用PreparedStatement绑定参数，或MyBatis中禁用${}、只用#{}，辅以白名单校验；Filter仅适合日志告警，不可修改请求体。
Filter里不能直接转义SQL字符
Filter本身不处理SQL语句，它只拦截HTTP请求和响应。所谓“对SQL字符转义”，本质是防止SQL注入，但这个动作必须发生在SQL拼接之前——通常在DAO层或ORM框架内部。把转义逻辑塞进Filter，不仅位置错、时机错，还会破坏请求体原始语义（比如JSON里的'或"被误删），反而引发解析失败。
为什么常见Filter方案会失效
很多网上示例用Filter遍历request.getParameterMap()，对每个值做String.replace("'", "\'")之类操作。问题在于：
- 只覆盖
GET参数，漏掉POST正文（尤其是application/json）、multipart/form-data、path variable - 转义规则硬编码，无法适配不同数据库（如PostgreSQL用
$$定界符，MySQL用反引号） - 破坏原始数据：前端传
{"name": "O'Reilly"}，Filter改成O'Reilly后，JSON解析直接报JsonParseException - 绕过方式极多：攻击者改用
1=1/**/UNION/**/SELECT、Unicode编码、宽字节注入，纯字符替换完全无效
真正该做的三件事
防御SQL注入不是加一层Filter就能解决的，核心是切断拼接路径：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 所有数据库访问必须用
PreparedStatement，参数用setString()等方法绑定，让JDBC驱动负责底层转义 - 如果非要用动态SQL（如MyBatis），禁用
${}，只用#{}；检查所有@SelectProvider类是否拼接了未校验的字符串 - 对用户输入做最小化白名单过滤（如手机号只允许数字，用户名限制长度和字符集），而不是“转义”——后者永远追不上新漏洞变种
Filter能做的有限但关键的事
Filter唯一合理介入点是日志和告警：记录可疑请求特征，不修改数据。
立即学习“Java免费学习笔记（深入）”；
- 扫描
request.getQueryString()和request.getInputStream()（需缓存body）中是否含UNION SELECT、EXEC(、@@version等高危模式 - 匹配到时，写入审计日志并返回
400 Bad Request，但不要尝试“清理”内容 - 注意性能：正则匹配开销大，建议用
contains()快速筛出明显恶意串，再用精确正则二次确认
真正的SQL安全不在Web层，而在你写executeUpdate()那行代码之前有没有用?占位符——Filter连这行代码都看不见。
