单元测试无法验证接口是否存在SQL注入，因其不连接真实数据库、无法模拟WAF拦截与运行时拼接行为，仅能确认参数化查询等代码层安全实践是否落实。
单元测试无法“验证接口不存在SQL注入”，它只能验证你写的那部分数据访问逻辑是否安全——比如是否用了参数化查询、是否对输入做了必要过滤。真正的SQL注入风险藏在运行时拼接、框架未拦截、ORM误用、或中间件绕过等环节，这些不在单元测试覆盖范围内。
为什么单元测试不适合测SQL注入
SQL注入是运行时行为漏洞，依赖真实数据库响应、WAF策略、应用层拼接逻辑、甚至PHP magic quotes这类历史遗留机制。单元测试通常：
- 不连接真实数据库（用mock或内存DB），绕过了SQL解析、权限校验、报错回显等关键链路
- 无法模拟WAF拦截
--、UNION SELECT、SLEEP(5)等payload的实际处理路径 - 如果测试只断言“返回了User对象”，而没检查SQL执行语句本身，就等于在验证业务逻辑，不是在验证安全性
单元测试中真正该断言的安全点
聚焦你能控制的代码层：DAO/Repository/Service里构造SQL或调用ORM的地方。重点不是“注入失败”，而是“根本没机会注入”。
- 检查是否所有外部输入都进了
PreparedStatement的setString()、setInt()等方法，而不是字符串拼接"WHERE id = " + id - 若用MyBatis，确认XML里没出现
${param}，全用#{param}；动态SQL中<if test="name != null"></if>这类判断不引入拼接风险 - 若用JPA/Hibernate，避免
entityManager.createNativeQuery("SELECT * FROM user WHERE name = '" + name + "'")，改用setParameter("name", name) - 对自定义SQL构建工具（如QueryDSL、jOOQ），断言生成的
Query对象是否含绑定参数，而非原始SQL字符串
比单元测试更有效的前置卡点
把检测左移到开发阶段，比写一堆“没报错就算过”的单元测试更实在：
- CI流水线里加静态扫描：用
semgrep规则匹配executeUpdate.*+.*request.getParameter、createQuery.*".*\+.*"等危险模式 - IDE插件实时告警：IntelliJ的SQL Injection Inspection、VS Code的SonarLint，能直接标红
String sql = "SELECT * FROM t WHERE id = " + req.getId(); - 数据库连接池层加审计：HikariCP + p6spy，记录所有实际执行的SQL，跑一遍接口测试后检查日志里有没有
1=1、OR 21=21、AND SLEEP等特征 - 本地启动一个带日志的PostgreSQL/MySQL容器，让测试用例连它，再用
pg_stat_statements或SHOW PROCESSLIST抓取执行语句，人工抽检是否含用户输入的原始值
最常被忽略的一点：很多团队花时间给UserService.findById(id)写10个SQL注入测试用例，却从不看ReportController.exportExcel()里那个用StringBuilder拼WHERE条件的私有方法——安全盲区永远在“非标准路径”。
