htmlspecialchars()仅用于HTML输出转义，非万能XSS防护；输入校验用filter_input()，数据库操作必须预处理，文件上传需验证MIME并重命名。
PHP 中最常用也最容易误用的过滤函数是 htmlspecialchars()
它不是用来“过滤输入”，而是专门用于“输出到 HTML 时转义特殊字符”。很多初学者把它当成万能防 XSS 的过滤器，结果在 SQL 查询、JSON 输出或文件写入场景中照常出问题。
常见错误现象：htmlspecialchars($_POST['name']) 后直接拼进 SQL 语句，导致单引号没被处理，SQL 注入依然存在；或者对已转义过的字符串反复调用，变成 zuojiankuohaophpcn 这类双重编码。
- 只在输出到 HTML/HTML 属性/JS 字符串内时使用，且必须指定
ENT_QUOTES和真实字符编码（如UTF-8） - 永远不要用它替代数据库参数绑定，也不要用它处理非 HTML 场景的输入
- 如果用户输入要存进数据库，
htmlspecialchars()应该完全不出现——那是mysqli_real_escape_string()或预处理语句的事
从表单接收数据后，第一步该用 filter_input() 做类型校验
这是 PHP 内置但常被忽略的安全入口。它比手写 isset() + is_numeric() + trim() 更可靠，且支持白名单过滤逻辑。
$_id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($$_id === false || $$_id === null) {
die('Invalid ID');
}
// 此时 $$_id 是整数，可安全用于 WHERE id = ?
- 用
FILTER_SANITIZE_EMAIL处理邮箱字段，比正则更轻量且符合 RFC 标准 -
FILTER_SANITIZE_NUMBER_INT可去掉所有非数字字符，适合手机号、邮编等，但会删掉负号和小数点 - 注意：所有
FILTER_SANITIZE_*类型都会修改原始值，不能替代验证；真正需要强约束时，优先用FILTER_VALIDATE_*+ 显式判断
数据库写入必须用预处理语句，mysql_real_escape_string() 已废弃且不安全
PHP 7.0+ 已移除 mysql_* 函数族，而 mysqli_real_escape_string() 依赖连接上下文和字符集设置，一旦 SET NAMES 和实际连接编码不一致，就会绕过转义。
立即学习“PHP免费学习笔记（深入）”；
正确做法只有一条：无论 MySQLi 还是 PDO，全部走预处理。
$stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (?, ?)");
$stmt->execute([$_POST['name'], $_POST['email']]);
- PDO 需确保创建时设置了
PDO::ATTR_EMULATE_PREPARES => false，否则仍可能触发模拟预处理，失去防护效果 - 不要把
filter_var()和预处理混用成“双重保险”——类型校验归校验，SQL 安全归预处理，职责分开才可控 - 如果必须动态拼表名或字段名（极少见），只能通过白名单硬编码比对，绝不可过滤后拼接
上传文件的 $_FILES 不能靠扩展名过滤，要验证 MIME 和内容
攻击者只需改个 .jpg 后缀，里面塞 PHP 代码，再配合 Apache 解析漏洞或 Nginx 配置失误就能执行任意代码。仅检查 $_FILES['file']['type'] 完全无效——那是浏览器传来的，可随意伪造。
- 用
finfo_open(FILEINFO_MIME_TYPE)检查真实 MIME 类型，例如强制只允许image/jpeg - 重命名上传文件，用随机字符串 + 白名单扩展名（如
uniqid() . '.jpg'），彻底丢弃原始文件名 - 上传目录禁止执行权限，Nginx/Apache 配置中明确禁止该目录下解析 PHP
实际项目里，最常被跳过的环节是「输出上下文识别」：同一段用户数据，可能同时出现在 HTML 页面、JS 变量、CSS 属性、URL 参数、CSV 导出里——每个上下文需要不同的转义方式。漏掉一个，就等于在防火墙上凿了个洞。