代码审计是唯一能触及SQL注入深层隐患的手段，因其可穿透框架封装、ORM混用、日志埋点及中间件自动构造SQL等非显性拼接路径，而渗透测试受限于HTTP闭环与WAF拦截，无法覆盖无响应、非请求链路的拼接点。
代码审计不是“更优”，而是唯一能触及SQL注入深层隐患的手段——当漏洞藏在框架封装、ORM混用、日志埋点或中间件自动构造SQL的路径里时，黑盒测试根本收不到响应。
为什么渗透测试会漏掉真实拼接点
渗透测试依赖HTTP请求-响应闭环，但很多SQL拼接根本不出现在请求链路里：
- X-Trace-ID头被中间件拿去拼INSERT INTO audit_log，但测试没发这个Header
- 用户输入先写进Redis缓存键，再由后台定时任务读出拼SQL，整个过程无HTTP交互
- MyBatis的<script></script>标签里写了${param}，而#{param}才是预编译——这种混用在响应体里完全不可见
- WAF拦截了' OR '1'='1，但后端仍存在String sql = "SELECT * FROM user WHERE id = " + userId;，只是payload被前置过滤了
代码审计必须盯死这三类非显性拼接
人工审计要主动穿透框架抽象层，不能只搜executeQuery：
- 框架封装调用：Laravel的DB::select("SELECT * FROM users WHERE name = '" . $input . "'")，表面是安全API，实则裸拼
- ORM中的原始SQL片段：Django的.extra(where=["status = '{}'".format(user_status)])，format绕过所有参数化保护
- 非DAO层拼接：Spring Boot中@Scheduled方法从@Value("${sql.template}")读配置，再用String.format()注入变量
审计时怎么判断“这里算不算拼接”
关键看数据流是否跨过类型边界：
- 用户输入是String，最终进了Statement.executeQuery(String) → 高危
- 输入先转Integer.parseInt()，再拼进SQL → 仍危险（数字型注入可绕过强转）
- 输入经PreparedStatement.setString(1, input) → 安全，但得确认input没被提前拼进另一条SQL
- 使用MyBatis时，#{id}安全，${id}危险，且${}在<bind></bind>或<script></script>里同样生效
真正难的不是找到conn.createStatement()，而是发现那个在LogUtils.generateKey()里把request.getRemoteAddr()和userAgent拼成缓存键、又被下游服务反查并拼进SQL的调用链——这种路径只有逐行追踪数据流向才能暴露。
