PHP无全局请求过滤机制，必须在业务层显式过滤：对整数用(int)或FILTER_VALIDATE_INT，邮箱用FILTER_VALIDATE_EMAIL，SQL用预处理，输出HTML用htmlspecialchars，且需区分过滤与验证。
PHP 默认不自动过滤请求数据，$_GET、$_POST、$_REQUEST 中的内容原样暴露，直接使用极易引发 XSS、SQL 注入或逻辑绕过。别指望“改个配置就能全局净化”——PHP 本身没有内置的请求过滤规则开关。
php.ini 里没有 request_filtering 这种选项
有人搜到 IIS 的 requestFiltering 或 ASP.NET 的类似机制，误以为 PHP 也有对应配置。实际上：php.ini 中不存在控制请求参数自动过滤的全局开关。magic_quotes_gpc（已废弃）和 filter.default（仅影响 filter_var() 默认行为）都不是请求入口级过滤方案。
-
filter.default = unsafe_raw是默认值，改它不会让$_GET['id']变安全 -
filter.default_flags只影响未显式传 flag 的filter_var($_GET['x'])调用，不改变原始超全局变量 - 启用
always_populate_raw_post_data（已移除）或调整enable_post_data_reading会影响读取方式，但不等于“过滤”
真正有效的过滤必须在业务层显式调用
过滤动作必须出现在你读取请求数据之后、使用之前。没有捷径，也没有“一次配置全站生效”的魔法。
- 对整数 ID：用
(int)强转或filter_var($id, FILTER_VALIDATE_INT) - 对邮箱：用
filter_var($email, FILTER_VALIDATE_EMAIL)，注意它不校验长度或 DNS - 对 HTML 输出场景：绝不能只靠
htmlspecialchars()入库前处理——那是输出编码，不是输入过滤 - 对 SQL 查询：用预处理语句（
PDO::prepare()/mysqli_prepare()），而非mysql_real_escape_string()（已废）或手动拼接
想“统一入口过滤”？自己封装一层，但要小心副作用
可以写一个 safe_input() 函数集中处理，但必须明确每种字段的语义和预期类型，不能无差别 strip_tags() 或 trim()：
立即学习“PHP免费学习笔记（深入）”；
function safe_input(string $key, string $type = 'string'): mixed {
$raw = $_GET[$key] ?? $_POST[$key] ?? null;
if ($raw === null) return null;
return match($type) {
'int' => filter_var($raw, FILTER_VALIDATE_INT),
'email' => filter_var($raw, FILTER_VALIDATE_EMAIL),
'string' => trim((string)$raw),
'url' => filter_var($raw, FILTER_VALIDATE_URL),
default => $raw
};
}
// 使用示例：
$user_id = safe_input('id', 'int');
if ($user_id === false) {
http_response_code(400);
exit('Invalid ID');
}
- 不要在封装里做
addslashes()或mysql_escape_string()—— 这会让后续 ORM 或 PDO 预处理重复转义 - 不要覆盖原始
$_GET，否则调试时找不到原始值，框架兼容性也成问题 - 如果用了 Laravel、Symfony 等框架，优先走其 Request Validation 机制（如
$request->validate()），别另起炉灶
最常被忽略的一点：过滤和验证是两件事。过滤是清理（如去掉空格、转为整数），验证是断言（如“必须是 1~100 之间的整数”）。很多所谓“净化”失败，是因为只做了前者，没做后者；或者把输出编码（htmlspecialchars()）错当成输入过滤。真正的安全起点，是每次从 $_GET 或 $_POST 拿值时，都问一句：这值接下来怎么用？该信谁？
