html转义对sql注入完全无效，因其仅作用于浏览器渲染层；唯一有效防护是参数化查询，通过分离sql结构与用户数据，由数据库驱动自动安全绑定参数。
单纯对输入内容做 HTML 转义 完全不能防止 SQL 注入，这是最常被误解的安全误区。HTML 转义只影响浏览器渲染，对数据库查询毫无作用；真正起效的是参数化查询（预编译）。
为什么 HTML 转义对 SQL 注入无效
SQL 注入发生在服务器拼接 SQL 字符串时，比如：SELECT * FROM messages WHERE content = '$_POST[content]'。即使用户输入 <script>alert(1)</script>，HTML 转义后变成 <script>alert(1)</script>，但数据库看到的仍是原始恶意 SQL 片段（如 ' OR 1=1 --），转义根本没参与 SQL 构建过程。
常见错误场景：
- 前端用
htmlspecialchars()处理后再发给后端，后端仍直接拼接进 SQL - 后端对
$_POST['name']做了htmlentities()，接着又写"INSERT INTO msg VALUES ('" . $_POST['name'] . "') - 把防 XSS 和防 SQL 注入混为一谈，以为“都叫转义，应该通用”
必须用预编译（参数化查询）
核心原则：让 SQL 结构和数据彻底分离。数据库驱动负责把参数值安全地绑定进预编译语句，不再经过字符串拼接。
PHP + MySQLi 示例（面向对象）：
$stmt = $mysqli->prepare("INSERT INTO messages (content, author) VALUES (?, ?)");
$stmt->bind_param("ss", $_POST['content'], $_POST['author']);
$stmt->execute();
关键点：
-
?占位符不接受任何 SQL 语法，仅作为纯数据容器 -
bind_param("ss", ...)中的"ss"明确声明两个参数都是字符串类型，驱动自动处理引号、转义、编码 - 即使
$_POST['content']是' OR 1=1 --，最终执行的也是带合法引号包裹的字面量：VALUES ('\' OR 1=1 --', '...')
哪些地方容易漏掉预编译
不是所有 SQL 都能用 ? 占位——动态表名、列名、ORDER BY 子句等不支持参数化。这时必须白名单校验，而非拼接+过滤：
- 表名动态？用
in_array($table_name, ['messages', 'comments', 'users'], true)严格比对 - 排序字段动态？只允许
['id', 'created_at', 'author']中的值，拒绝$_GET['sort']的任意输入 - WHERE 条件数量不定？用循环生成对应数量的
?，再调用bind_param动态传参（PHP 8.1+ 支持...$params展开） - 用 ORM（如 Laravel Eloquent、ThinkPHP QueryBuilder）？确认其底层是否真正使用预编译——有些“伪参数化”仍会拼接字符串
额外注意：过滤函数不是替代方案
像 mysql_real_escape_string()（已废弃）、addslashes() 或正则替换单引号，都不可靠：
- 多字节编码漏洞（如 GBK）下，
%A1%27可绕过addslashes() - 数字型注入（如
id=1 OR 1=1）根本不需要引号，过滤无意义 - JSON 字段、LIKE 模糊查询中的通配符（
%、_）需单独处理，不能依赖统一过滤
真正的修复只有唯一路径：所有用户可控输入进入 SQL 的位置，必须走预编译。其他手段只是补丁，且大概率失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
