sonarqube通过追踪“用户输入→未过滤拼接→执行函数”完整数据流识别sql注入，而非仅检测sql字符串内容；硬编码不触发告警，mybatis注解需专用插件支持，漏报多因污点传播中断或扫描配置缺失。
SonarQube 能发现 SQL 注入隐患，但不是靠“看到 SQL 字符串”就报警——它必须确认「用户输入 → 未过滤拼接 → 流向执行函数」这条链路完整存在。漏报或误报，几乎都卡在这三步的某一个环节没识别准。
为什么 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()等已知执行点，链路闭合，立即报java:S2077或javascript: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()参数无法被标记为污点源
为什么已知拼接代码没被扫出来？先查这四件事
不是规则失效，而是扫描环境没把上下文“喂”对：
- 项目未声明语言类型：Maven 子模块缺
<packaging>jar</packaging>，或 JS 项目无package.json，Scanner 直接跳过目录 - SQL 执行逻辑藏在自研 ORM 或反射调用里（如
Method.invoke(..., "executeQuery")），默认规则不认识，需配置sonar.java.libraries或自定义规则 - 问题代码在
src/test/下，默认被排除；加-Dsonar.exclusions=反向取消排除才能扫测试代码 - 用了非标准入口，比如从
HttpServletRequest.getAttribute()取参，而非getParameter()—— 默认污点源列表不包含它，需扩展规则或改用标准方式
修复时别只改一行，要拆掉整条风险链
把 "WHERE name = '" + name + "'" 改成 "WHERE name = ?" 是治标；真正要动的是数据流动路径：
- 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 构造路径都绕不开占位符机制。
