动态报表系统中禁止SQL字符串拼接，必须用白名单校验标识符并严格参数化用户数据。报表场景因需动态调整WHERE、ORDER BY等易受注入，应剥离动态逻辑交由预编译与应用层协同控制。
动态报表系统中不能安全拼接 SQL —— 任何字符串拼接都等于给攻击者留后门。 即便你加了过滤、转义或白名单，只要最终生成的是 String 类型的完整 SQL 并交给 Statement.execute() 执行，就存在绕过可能。真正的安全路径是：把“动态”从 SQL 字符串里剥离出来，交由数据库预编译机制和应用层逻辑共同控制。
为什么报表场景下拼接特别危险
报表系统常需动态调整 WHERE 条件、ORDER BY 字段、GROUP BY 维度甚至表名，这些都不是普通参数能覆盖的范畴。而攻击者清楚这点，会专门试探：ORDER BY 后注入 1, (SELECT @@version)；在表名位置塞入 users; DROP TABLE logs--；或利用 UNION SELECT 抽取敏感字段。一旦你用 String.format() 或 StringBuilder 拼出整条语句，数据库根本分不清哪部分是结构、哪部分是数据。
只允许白名单控制的动态标识符
对必须动态的部分（如排序字段、分组字段、表别名），绝不能直接代入用户输入。必须走硬编码白名单校验：
- 定义允许的字段列表：
Set<String> ALLOWED_SORT_FIELDS = Set.of("create_time", "amount", "status") - 用户传参只接受字段名字符串，但必须严格比对：
if (!ALLOWED_SORT_FIELDS.contains(sortField)) throw new IllegalArgumentException("Invalid sort field") - 表名、列名等标识符禁止使用
?占位符（JDBC 不支持），只能靠正则过滤：sortField.matches("^[a-zA-Z][a-zA-Z0-9_]*$")，且必须配合白名单双重校验 - 注意：正则
^[a-zA-Z0-9_]+$虽能防基本注入，但无法防sysobjects这类合法但危险的系统表名，所以白名单优先级永远高于正则
参数化查询仍是唯一可信的数据入口
所有用户实际输入的值（日期范围、关键词、状态码等），必须无条件走 PreparedStatement 参数绑定：
- 模糊查询不要写
"%"+keyword+"%"，而应在 SQL 中写LIKE ?，然后pstmt.setString(1, "%" + keyword + "%") - 多选条件用
IN时，不能拼"IN ('a','b')"，应根据参数个数动态生成占位符：String placeholders = String.join(",", Collections.nCopies(ids.size(), "?"))，再绑定每个id - 数值范围用
BETWEEN ? AND ?，不拼字符串；布尔值用= ?，不拼'true' - MyBatis 用户注意：
${}是字符串替换，#{}才是参数化 —— 所有用户输入必须进#{}，${}只能用于白名单内的静态标识符
别信“已转义就安全”的幻觉
手写转义函数（比如把单引号替换成两个单引号）在复杂上下文里极易失效。例如：
- MySQL 中
SET sql_mode='NO_BACKSLASH_ESCAPES'会让反斜杠失效 - 某些驱动或中间件会二次解析，导致双单引号被还原
- JSON 输入、URL 编码、Base64 等多层编码可能绕过前端过滤
- 最致命的是：你永远不知道下一个数据库补丁会不会改变字符串解析行为
真正难啃的骨头不在怎么“加固拼接”，而在怎么把“拼接需求”本身从设计里拿掉 —— 比如用视图封装常用维度组合，用存储过程收口高频报表逻辑，让动态性发生在受控的数据库层，而非应用层字符串操作中。
