必须用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 就自动免疫。