生产环境查SQL注入需盯住三类代码：手动拼接SQL、MyBatis中危险的${}用法、绕过框架过滤的自定义接口；重点扫描${}动态参数是否经白名单校验，排查日志中SQL报错与可疑请求，审计是否绕过若依SQLFilter。
生产环境里查 SQL 注入，不能靠猜，得盯住三类代码：手动拼接 SQL 的地方、用了 ${} 的 MyBatis 语句、以及绕过框架过滤的自定义接口。
查 MyBatis 中危险的 ${} 用法
MyBatis 的 ${} 是字符串原样替换，不转义、不预编译，只要参数可控，就等于给攻击者开了后门。重点扫 XML 文件和注解里的 @Select、@Update 等，尤其注意动态表名、字段名、ORDER BY 子句这类必须用 ${} 的场景。
- 搜索所有
${username}、${tableName}、${sortField}等模式，逐个确认是否做了白名单校验 - 检查是否用了
StringUtils.isAlphanumeric()或正则^[a-zA-Z0-9_]+$严格限制字段名，而不是简单 trim 或非空判断 - 若必须动态表名，优先改用枚举或配置映射，避免直接从 HTTP 参数取值
翻日志，找可疑的 SQL 报错或异常返回
数据库报错信息（比如 MySQL 的 MySQLSyntaxErrorException、PostgreSQL 的 PSQLException）如果被回显到前端或日志里，往往暴露了注入痕迹。生产环境开启慢查询日志 + 错误日志归集后，可以快速定位异常模式。
- 在 ELK 或 Loki 中搜索关键词：
SQL syntax、near '、Unknown column、UNION SELECT - 关注高频出现的单引号
'、分号;、注释符--、#出现在 URL query 或 POST body 中的请求 - 特别留意状态码为 200 但响应体含大量数据库结构信息（如表名、列名、版本号）的请求——这很可能是盲注成功后的试探行为
审计自定义 SQL 接口是否绕过了若依的 SQLFilter
若依框架自带 SQLFilter 拦截器，但只对 Controller 层标准路径生效。一旦新增接口没走统一入口（比如用了 @RestController 却没加 @RequestMapping 前缀），或者用了 Feign/HttpClient 直连，就可能跳过过滤。
- 检查所有新写的 Controller 方法，确认其 mapping 路径是否匹配
SQLFilter的urlPatterns配置（默认是/api/**、/system/**等） - 搜索项目中是否有
@WebFilter或excludePathPatterns显式排除了某些路径 - 对未走 Controller 的 DAO 层调用（如直接 new Mapper 执行），需单独补上参数合法性校验，不能依赖框架层防护
最麻烦的不是找到漏洞，而是确认“这个参数到底控不控”——很多看似安全的字段（比如用户传来的 tenantId、lang）在多租户或国际化场景下，其实也参与了 SQL 拼接。别信变量名，得顺着调用链一路跟到最终执行的 SQL 字符串。
