用户提交的每一个数据都不可信，这是Web安全的基本前提。无论是表单、URL参数还是Cookie，只要来自客户端，就可能被构造恶意内容。PHP提供了从内置过滤函数到预处理语句的多层手段，关键是搞清楚每种方法各自解决什么问题，以及在什么位置做过滤最合适。本文结合实际代码，把PHP输入过滤的完整思路梳理一遍。
一、使用filter_var和filter_input做结构化校验
很多人把输入过滤简单理解为"转义"，其实第一步应该是校验：判断数据格式是否符合预期。PHP内置的Filter扩展非常适合做这件事，它不需要额外安装，从PHP 5.2起就默认启用。核心函数有两个：filter_var()作用于一个已经拿到的变量，filter_input()则直接从超全局数组中读取并过滤，后者能避免你先接触原始数据，安全性更好。
常用的过滤器分两类：验证类（FILTER_VALIDATE_*）负责判断格式对不对，返回原值或false；清理类（FILTER_SANITIZE_*）负责把不合法的部分剔除或转换。下面是一段综合示例：
<?php
// 验证邮箱格式，注意 5.2 之后的 FILTER_VALIDATE_EMAIL
$email = $_POST['email'] ?? '';
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
exit('邮箱格式不正确');
}
// 验证整数并限定范围
$age = filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT,
['options' => ['min_range' => 1, 'max_range' => 120]]);
if ($age === false || $age === null) {
exit('年龄必须是 1 到 120 之间的整数');
}
// 清理字符串：去掉标签、去除首尾空白
$name = filter_input(INPUT_POST, 'name', FILTER_SANITIZE_STRING);
// PHP 8.1 起 FILTER_SANITIZE_STRING 已废弃，改用 htmlspecialchars 处理
$name = trim(htmlspecialchars(strip_tags($_POST['name'] ?? '')));
?>需要留意的是，FILTER_VALIDATE_EMAIL并不能证明邮箱真实存在，它只检查语法格式。另外FILTER_SANITIZE_STRING在PHP 8.1中已被废弃，新项目建议用strip_tags()加htmlspecialchars()的组合替代。校验失败时的策略要明确：要么拒绝请求，要么给用户友好提示，不要默默"修正"数据后继续执行，那样容易掩盖攻击尝试。
二、不同输出场景要区别对待：SQL注入与XSS的防御
输入过滤容易犯的第二个错误，是想用一套规则对付所有风险。实际上，SQL注入和XSS的防御位置完全不同。防SQL注入的正确做法是预处理语句，让数据和SQL结构彻底分离，而不是手动拼接后靠addslashes"过滤"：
<?php
// 错误做法：拼接SQL，即使做了addslashes仍有绕过风险
$sql = "SELECT * FROM users WHERE name = '" . addslashes($name) . "'";
// 正确做法：PDO预处理
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', 'user', 'pass', [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false, // 关闭模拟预处理，更安全
]);
$stmt = $pdo->prepare('SELECT * FROM users WHERE name = ? AND status = ?');
$stmt->execute([$name, $status]);
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>而XSS的防御位置在输出端。数据入库时保留原样，输出到HTML时用htmlspecialchars()转义，这样才能既不破坏原始数据，又保证渲染安全。记住口诀："输入时校验，输出时转义，SQL用预处理"。如果想偷懒在入库时统一转义，一旦这份数据还要输出到JavaScript或CSV，反而会产生二次污染问题。
<?php // 输出到HTML上下文时转义 echo htmlspecialchars($userComment, ENT_QUOTES, 'UTF-8'); // 输出到URL时用另一套规则 echo urlencode($keyword); ?>
三、封装一套自己的过滤流程与常见误区
实际项目中，建议把"读取、校验、清理"封装成统一入口，避免各处代码各自为战。一个简单可行的做法是写一个白名单式的取参函数：
<?php
function fetchParam(string $key, string $type = 'string', $default = null)
{
$raw = $_POST[$key] ?? $_GET[$key] ?? $default;
if ($raw === null) {
return $default;
}
switch ($type) {
case 'int':
$v = filter_var($raw, FILTER_VALIDATE_INT);
return ($v === false) ? $default : $v;
case 'email':
$v = filter_var($raw, FILTER_VALIDATE_EMAIL);
return ($v === false) ? $default : $v;
default:
// 去首尾空白 + 去标签，保留原始内容用于输出时再转义
return trim(strip_tags((string)$raw));
}
}
$uid = fetchParam('uid', 'int', 0);
?>最后提醒几个高频踩坑点。第一，不要依赖magic_quotes_gpc的思路，这个特性在PHP 5.4就已移除，历史代码里看到的stripslashes()调用要结合上下文判断是否还需要。第二，不要用正则去"过滤"SQL注入，比如简单替换引号，GBK宽字节注入等手法可以绕过这类做法。第三，文件上传必须检查MIME类型和服务端后缀白名单，仅靠客户端校验形同虚设。第四，校验要尽量严格：用白名单限定允许的字符集和长度，比黑名单列举危险字符可靠得多。
总结一下，PHP输入过滤的核心是分层处理：入口处用filter系列函数校验格式和类型，数据库操作统一走预处理语句，HTML输出统一走htmlspecialchars转义，文件上传单独做白名单。把这套流程固化到公共函数或中间层里，安全性和可维护性都会明显提升。
PHP输入过滤数据安全过滤filter_var修改时间：2026-09-15 11:22:37