php接口应优先用filter_var()清洗数据：邮箱用filter_sanitize_email+filter_validate_email，整数用filter_validate_int防类型混淆，禁用已废弃的filter_sanitize_string，json数据需手动逐字段过滤，且须处理unicode空白和null字节。
PHP接口里怎么用filter_var()做基础清洗
直接上手最稳妥：接口收到的数据，别急着入库或计算，先过一遍filter_var()。它不是万能的，但对邮箱、URL、整数、浮点这些常见类型，比手写正则快且安全。
比如用户传了email字段，别用trim()加strpos('@')判断——那是自找麻烦：
$_POST['email'] = ' test@domain.com ';
$email = filter_var($_POST['email'], FILTER_SANITIZE_EMAIL); // → 'test@domain.com'
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
die('{"error":"invalid email"}');
}
-
FILTER_SANITIZE_EMAIL会删掉所有非法字符，但不校验格式是否合法；验证必须另用FILTER_VALIDATE_EMAIL - 整数清洗别用
(int)强转——"123abc"会变成123，而filter_var("123abc", FILTER_VALIDATE_INT)直接返回false -
FILTER_SANITIZE_STRING在PHP 8.1+已被移除，别再用；改用htmlspecialchars()或filter_var($str, FILTER_SANITIZE_SPECIAL_CHARS)
为什么$_GET和$_POST不能直接信任
很多人以为“我只收POST”，就等于数据干净了。错。攻击者可以curl伪造任意Content-Type，也能在GET里塞id=1%3Cscript%3Ealert(1)这种编码过的XSS payload。
关键点在于：清洗动作必须发生在你第一次读取变量之后、任何业务逻辑之前。哪怕只是echo $_POST['name']，也得先清洗。
- 别在SQL查询里用
mysqli_real_escape_string()代替清洗——它只防SQL注入，不防XSS或业务逻辑错乱 -
$_REQUEST更危险，它混了GET、POST、COOKIE，优先级还依赖variables_order配置，建议彻底禁用 - 数组字段如
tags[]=a&tags[]=b，filter_var_array()能批量处理：filter_var_array($_POST, ['tags' => FILTER_SANITIZE_STRING])
JSON接口怎么清洗json_decode()后的数据
用file_get_contents('php://input')拿到原始JSON，json_decode()后得到的是PHP数组或对象——这时候filter_var()不能直接套用，得递归或逐字段处理。
简单场景（如只有几个固定字段）推荐手动指定规则：
$raw = file_get_contents('php://input');
$data = json_decode($raw, true);
if (json_last_error() !== JSON_ERROR_NONE) {
http_response_code(400);
die('{"error":"invalid json"}');
}
$clean = [
'title' => filter_var($data['title'] ?? '', FILTER_SANITIZE_SPECIAL_CHARS),
'price' => filter_var($data['price'] ?? 0, FILTER_VALIDATE_FLOAT),
'in_stock' => filter_var($data['in_stock'] ?? false, FILTER_VALIDATE_BOOLEAN),
];
-
FILTER_VALIDATE_BOOLEAN会把字符串"false"、"0"、空数组都转成false，符合多数API语义 - 别用
json_decode($raw, false)（返回对象），因为对象属性无法用filter_var()直接处理，还得转回数组 - 深层嵌套结构（如
user.profile.phone）建议写个轻量递归函数，而不是堆isset()和??
容易被忽略的边界：编码、空格、NULL字节
清洗不是只盯着字母数字。UTF-8 BOM头、全角空格、零宽字符、\x00这些，filter_var()基本不管，但可能让后续逻辑出错甚至绕过校验。
- 用
mb_trim()（需自己写）或preg_replace('/^\s+|\s+$/u', '', $str)处理Unicode空白，trim()对中文空格无效 -
str_replace("\x00", '', $str)必须加——尤其当数据要进shell命令或二进制存储时 - 前端传
null，PHP收到的是字符串"null"还是真的NULL，取决于JSON解析方式，务必用is_null()或=== null明确判断，别信empty()
真正难的不是写清洗逻辑，而是每次新增一个字段、换一种输入方式（表单/JSON/Query）时，都记得补上对应清洗步骤。漏掉一个，就可能让整个清洗体系失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
