把条件判断留在SQL里等于留后门，因动态SQL将业务分支逻辑交由不可信输入控制，易引发注入；应由Java层用枚举、白名单、参数化等机制收编控制权。
为什么把条件判断留在SQL里等于留后门
动态SQL最危险的不是拼接本身，而是把本该由业务逻辑决定的分支，硬塞进SQL字符串里。比如WHERE status = 'active' AND type IN ('A', 'B')这种写法，看着安全，但一旦type列表来自用户输入且没走参数化，就立刻退化成IN ('A', 'B', "'); DROP TABLE users; --")。
数据库只管执行，不负责校验语义；而业务层能做白名单、类型断言、范围限制——这才是第一道防线。
- 所有
IN子句必须转为固定占位符数量：先算出输入长度，生成?, ?, ?再传参，别用${typeList}或JOIN(',', userTypes) -
ORDER BY字段禁止直接插变量，改用枚举或Map.of("name", "u.name", "created", "u.created_at")映射后白名单校验 - 模糊搜索的
LIKE通配符必须由代码加，不能让用户输%admin%再原样塞进SQL；正确做法是setString(1, "%" + userInput.trim() + "%")
MyBatis里#{}和${}混用时怎么拆解逻辑
很多老项目在<if test="sortBy != null">ORDER BY ${sortBy}</if>这种写法上栽过跟头——${}根本绕过MyBatis参数绑定，等价于字符串拼接。重构不是简单替换成#{}（那会报错），而是要把结构控制权交还给Java。
- 把
sortBy从String改成枚举：public enum SortField { NAME, CREATED_AT, STATUS }，XML里用<if test="sortField == 'NAME'">ORDER BY u.name</if> - 对
IN类动态条件，放弃<foreach></foreach>拼${}，改用Collection<string> types</string>入参，Java层生成对应数量的?并调用setString(i, type) - 遇到必须动态表名的场景（如分表），提取为配置项：
@Value("${user.table.prefix:users}") String tablePrefix，再硬编码拼FROM ${tablePrefix}_2026——至少这个值不可被用户控制
Java PreparedStatement里最容易忽略的三个坑
很多人以为用了PreparedStatement就万事大吉，其实漏洞常藏在“外面一层”。比如日志里看到executeQuery("SELECT * FROM " + tableName + " WHERE id = ?")，预编译对象拿到的已是完整字符串，?早没意义了。
codex-orchestration
下载
一款AI工具，主要用于Codex 通用编排：利用 `update_plan` 与后台 PTY 终端并行运行 `codex exec` 工作进程，适合需要提升相关任务效率的用户。
-
Statement和PreparedStatement不能混用：搜全项目conn.createStatement()，凡带用户输入的都得重写 -
setString()索引从1开始，写成setString(0, val)会抛SQLException但不报注入——只是功能失效，容易漏测 - 批量操作别用循环
executeUpdate()，改用addBatch()+executeBatch()，否则每条SQL都是独立字符串，数据库无法复用执行计划
重构时怎么快速定位隐藏的动态SQL
别指望单元测试能发现注入点——正常输入下它永远绿。真正要盯的是那些“不该被接受却通过了”的输入。最有效的扫描方式是代码+运行时双轨。
- 静态扫描：全局搜
"SELECT、"INSERT、"UPDATE、"DELETE、.execute(、.query(、@Query.*nativeQuery = true、${，逐个确认是否含用户输入 - 运行时验证：在DAO层加AOP拦截，打印所有实际执行的SQL，人工抽检含
?的位置是否真被参数填充，还是被"" + input提前污染 - 特别注意JSON解析后的字段：比如
new ObjectMapper().readValue(json, Map.class)拿到的map.get("table")，极易被当成可信值直接拼SQL
动态SQL的“动态”二字，本质是把控制权让渡给了不可信输入。重构不是让SQL更灵活，而是把灵活性收回到类型安全、可审计、可测试的Java代码里——表名、字段、排序逻辑这些结构性的东西，本就不该出现在SQL字符串中。
