必须用PreparedStatement替代字符串拼接，将用户输入作为参数传入而非拼入SQL；禁止使用--、;、UNION等任意拼接，过滤非根本解法，动态SQL需严格白名单校验。
直接把用户输入拼进 SQL 字符串、还允许它触达注释位置（比如 --、# 或 /* */ 边界），等于主动给攻击者递刀。这种写法在任何语言里都不可接受，修复不是“加个过滤”就能完事，而是必须切断拼接链。
用 PreparedStatement 替代字符串拼接（Java / JDBC 场景）
这是最直接、最可靠的切断方式。数据库驱动会把参数值当作纯数据处理，不参与 SQL 语法解析，-- 在参数里就是两个普通字符，不会被识别为注释起始。
- 错误写法：
String sql = "SELECT * FROM users WHERE name = '" + name + "'";—— 用户输admin'--就能绕过密码校验 - 正确写法：
String sql = "SELECT * FROM users WHERE name = ?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, name); - 注意：
setXXX()方法必须传入原始值，不要自己手动加引号或转义；否则反而破坏预编译机制
别信“过滤掉 --”这种临时补丁
单纯用 replace("--", "") 或正则删注释符，既漏报也误杀：攻击者可用 %2D%2D、/**/、#（MySQL）、甚至编码嵌套绕过；而合法用户名如 user--backup 会被截断成 user，业务逻辑出错。
- 真实风险点不止
--：分号;（多语句执行）、括号()（函数调用）、UNION SELECT（数据窃取）同样危险 - 过滤是防御纵深的一环，但绝不能作为主要手段——它解决不了语法结构被篡改的根本问题
动态 SQL 真绕不开？那就严格限定变量作用域
极少数场景（如报表引擎、权限字段动态拼接）确实需要构建 SQL 字符串。此时必须把用户可控部分限制为白名单枚举值，而非任意字符串。
- 例如排序字段：
if (!Arrays.asList("name", "email", "created_at").contains(sortField)) throw new IllegalArgumentException(); - 表名/列名不能来自请求参数，必须映射到内部定义的常量或配置项
- 如果用了 MyBatis 的
${}，立刻检查所有使用点——它不做任何转义，等同于字符串拼接；应全部改为#{}
最易被忽略的一点：ORM 框架（如 Hibernate、SQLAlchemy）的原生查询接口（createNativeQuery、text()）同样跳过参数化机制，只要用了字符串插值，就和手写拼接无异。修复时得逐行扫这些调用点，不是加了 ORM 就自动免疫。
