JSON解析后直接拼SQL属高危行为，必须用预处理语句；表名、字段名、JSON路径、排序字段等动态部分须白名单校验；IN查询需动态占位符；DTO绑定不等于SQL安全。
json_decode 后直接拼 SQL 字符串，等于把数据库大门钥匙交给前端——无论字段值看着多“正常”，只要没走参数化查询，就是高危状态。
PHP 中 json_decode 后必须用预处理语句
常见错误是：json_decode($json, true) 得到数组，再用 "INSERT INTO t (name) VALUES('".$row["name"]."')" 拼 SQL。一旦 $row["name"] 是 NASA's 或 admin' --，SQL 就崩，且可被注入。
正确做法：
- 用
PDO或MySQLi的预处理：先$stmt = $pdo->prepare("INSERT INTO t (name) VALUES (?)")，再$stmt->execute([$row["name"]]) - 表名、字段名不能参数化？那就白名单校验：
in_array($table_name, ["news", "users", "logs"], true) - 别碰
mysql_real_escape_string或addslashes——它们依赖字符集，宽字节下形同虚设，且 PHP 7+ 已废弃
Java + Jackson + MyBatis 场景下只许用 #{}，禁用 ${}
${} 是字符串硬替换，#{} 才走 PreparedStatement。哪怕你加了 @Valid 或 DTO 强类型绑定，只要用了 ${id}，恶意输入照样进 SQL。
典型陷阱：
-
@Select("SELECT * FROM ${tableName} WHERE name = #{name}")——${tableName}必须白名单校验，#{name}才安全 -
WHERE content->>'${path}' = #{value}——${path}是 JSON 路径，必须限制为Set.of("title", "author")等固定值 - 动态排序如
ORDER BY ${sortField} ${sortDir}，两个变量都得完整匹配白名单条目，比如"created_at DESC"要整体在列表里，不能只校验字段名
JSON 数组转 IN 查询必须动态占位符
遇到 {"ids": [1,2,3]}，绝不能写成 "id IN (" . implode(",", $ids) . ")"，也不能用 ${ids} 拼接——这等于把攻击面直接暴露给数组长度和内容。
实操要点：
- MyBatis 推荐：
<foreach item="id" collection="filter.ids" open="id IN (" separator="," close=")">#{id}</foreach> - PDO 中需手动构建占位符：
$placeholders = str_repeat('?,', count($ids) - 1) . '?'; $sql = "SELECT * FROM t WHERE id IN ($placeholders)"; $stmt = $pdo->prepare($sql); $stmt->execute($ids); - PostgreSQL 若用
ANY(ARRAY[?])，参数必须传 PHP 数组，不是字符串；否则仍可能被绕过
强类型 DTO 绑定只是起点，不是防护终点
ObjectMapper.readValue(json, User.class) 能校验结构、类型、非空，但不会过滤内容。{"name": "admin'; DROP TABLE users; -- "} 反序列化后，user.getName() 还是那个字符串。
关键判断点：
- DTO 绑定通过 ≠ SQL 安全 —— 如果后续还用
"WHERE name = '" + user.getName() + "'"，等于前功尽弃 - 嵌套 JSON 或动态字段（如
{"custom": {"field": "xxx"}}）无法靠 DTO 绑定防护，字段名本身来自用户输入，必须白名单限制路径 - 所有从 JSON 解析出来的值，只要进 SQL，就得走
setString()、setLong()等明确类型的PreparedStatement方法，不能图省事用setObject()
真正容易被忽略的，是那些“看起来不危险”的地方：表名拼接、JSON 路径拼接、ORDER BY 动态字段、IN 列表构造——它们都不支持问号占位符，但开发者常误以为“反正没拼值，就没事”，结果成了注入入口。
