SonarQube 能够高效识别 SQL 注入风险，但其检测原理与多数人的直觉有所不同——它并非仅因字符串中包含 SQL 关键词就触发告警，而是必须追踪一条完整的数据流路径：用户输入 → 未过滤拼接 → 执行函数。理解这一机制后，便能解释为何某些代码段被标记为红色警告，而另一些看似更危险的代码却静默无闻。
简而言之，SonarQube 的检测核心是“追踪数据源头”，而非“分析字符串具体内容”。你可能会疑惑：为什么 String sql = "WHERE id = '" + req.getParameter("id") + "'" 会被标红，而 "WHERE id = '123'" 却完全不会？
为什么 String sql = "WHERE id = '" + req.getParameter("id") + "'" 会被标红，而 "WHERE id = '123'" 不会
关键差异在于：SonarQube 并不关注字符串内容是否危险，它只追踪变量的来源与流向：
req.getParameter("id")被自动标记为典型的污点源（taint source），属于 OWASP 定义的“不可信输入”- 通过
+或StringBuilder.append()直接拼接到 SQL 字符串中，触发“字符串拼接污染传播”规则 - 若该字符串最终被传递给
Statement.execute()、JdbcTemplate.query()或knex.raw()等已知执行节点，链路闭合，随即报告ja va:S2077或ja vascript:S2077 - 硬编码字符串无变量参与，不构成数据流，因此不会告警——即便内容为
' OR 1=1--'
这一设计实际非常巧妙，有效减少了误报；但这也意味着仅凭字符串内容做“直觉判断”在此处并不适用。
Spring Boot + MyBatis 场景下，@Select("SELECT * FROM user WHERE id = ${id}") 为何常被漏掉
默认扫描根本无法解析注解中的 SQL，因为 SonarQube 的 Java 插件并不内置 MyBatis 注解语法识别能力。很多人发现代码未被报错时，第一反应是规则失效，实则问题出在扫描环境配置上：
- 必须安装并启用 MyBatis Plugin for SonarQube（第三方插件，需手动下载与部署）
- 启用该插件后，
${id}才会被识别为危险拼接（对应于 MyBatis 的非参数化写法），而#{id}则不会触发告警 - XML 映射文件中的
同样依赖此插件；否则整段 SQL 语句对扫描器“完全不可见” - 使用 Lombok
@Data或@Builder可能导致 AST 解析失败，使得req.getParameter()参数无法被标记为污点源
换言之，并非扫描器不工作，而是它根本没有看到你的 SQL 语句结构。
为什么已知拼接代码没被扫出来？先查这四件事
遇到漏报情况，不要急着归咎于工具，首先应检查扫描环境是否已将上下文“喂”给正确：
- 项目未声明语言类型：Maven 子模块缺少
jar package.json，Scanner 会直接跳过该目录 - SQL 执行逻辑藏于自研 ORM 或反射调用中（如
Method.invoke(..., "executeQuery")），默认规则无法识别，需配置sonar.ja va.libraries或自定义规则 - 问题代码位于
src/test/下，默认被排除；可添加-Dsonar.exclusions=反向取消排除以扫描测试代码 - 使用了非标准入口，例如从
HttpServletRequest.getAttribute()获取参数，而非getParameter()—— 默认污点源列表不包含该方法，需扩展规则或改用标准方式
这些配置细节往往是在排查漏报时最容易被忽视的环节。
修复时别只改一行，要拆掉整条风险链
很多人看到告警后，第一反应是将 "WHERE name = '" + name + "'" 改为 "WHERE name = ?"，这当然正确，但治标不治本。真正需要调整的是数据流动路径，从根本上切断用户输入直接进入 SQL 的可能性：
- Java：优先使用
JdbcTemplate.query("...", new Object[]{name})，或迁移到 MyBatis 的#{name}占位符写法 - Node.js / Knex：禁止使用
knex.raw("WHERE id = " + req.query.id)，改用knex.where("id", req.query.id) - 若必须动态拼接字段名（如排序字段），采用白名单校验：
if (!Arrays.asList("name", "created_at").contains(sortField)) throw ... - 所有用户输入进入 SQL 前，必须经过参数化或白名单过滤——静态扫描不会替代运行时防护，它只是提醒你“此处可能存在风险”
最常被忽略的一点：规则本身无法保证 100% 覆盖，尤其当数据流跨越多个方法、经由中间对象传递，或使用非常规框架时，AST 解析可能断裂。与其纠结某处为何未报，不如将参数化作为强制契约，确保所有 SQL 构造路径都绕不开占位符机制。
