filter_input()是处理表单输入的首选起点，它从源头一体化完成取值、类型验证与过滤，天然规避未定义键、空值及类型混淆问题；返回false或null即表示字段无效或缺失，无需手动isset()判断；但验证通过不等于数据安全，数据库入库仍须预处理，输出到HTML前必须htmlspecialchars()转义。
filter_input() 是处理表单输入的起点，不是可选补充
直接从源头过滤比先取 $_POST 再清理更可靠——它天然规避了空值、未定义键、类型混淆等问题。你不需要手动写 isset() 或 empty() 判断，filter_input() 返回 false 或 null 就代表该字段无效或缺失。
-
filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL)只验证格式，不修改数据；若想同时清理再验证，得用两步：先FILTER_SANITIZE_EMAIL，再单独filter_var($cleaned, FILTER_VALIDATE_EMAIL) - 整数范围校验必须显式传
options：filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 120]])，漏掉数组包装会静默失败 - 字符串类清理慎用
FILTER_SANITIZE_STRING：PHP 8.1+ 已弃用，改用FILTER_SANITIZE_FULL_SPECIAL_CHARS（等价于htmlspecialchars()行为）或FILTER_SANITIZE_SPECIAL_CHARS
filter_var() 验证后不能直接入库，必须配合 PDO 预处理
验证通过只说明“看起来像邮箱”，不代表数据安全。有人会提交 "admin@example.com'; DROP TABLE users; -- " 这种字符串——filter_var($input, FILTER_VALIDATE_EMAIL) 依然返回 true，但拼进 SQL 就是灾难。
- 数据库写入必须走
$pdo->prepare()+$stmt->execute()，哪怕数据已用filter_input()处理过 - 别信
addslashes()或mysql_real_escape_string()：它们依赖字符集、易被绕过，且无法防御二阶注入 - 预处理防不了 XSS：存进数据库的
<script>alert(1)</script>被filter_var()放过，输出到 HTML 前仍要过htmlspecialchars()
输出时 htmlspecialchars() 不是“以防万一”，而是强制步骤
所有动态插入 HTML 的用户数据，无论是否经过过滤或验证，都必须转义。这不是重复劳动，而是分层防御的必要一环——过滤管输入，转义管输出，两者职责不同，不可互相替代。
- 用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，明确指定编码，避免因默认编码不一致导致转义失效 - 不要只在显示用户名时转义，也要覆盖错误提示、搜索关键词回显、评论内容等所有用户可控输出点
- 如果输出到 JavaScript 或 CSS 上下文，
htmlspecialchars()不够用，需用json_encode()或专用上下文转义函数
文件上传和 CSRF 是独立防线，不能靠过滤/验证覆盖
表单安全不止于字段内容。上传的文件可能带 shell 脚本，伪造请求可能绕过登录直接提交——这两类风险完全不在 filter_var() 或 filter_input() 的能力范围内。
立即学习“PHP免费学习笔记（深入）”；
- 别信
$_FILES['file']['type']：浏览器可随意伪造 MIME 类型，必须用finfo_file()读文件头确认真实类型 - CSRF token 必须服务端生成并绑定 session，提交时比对；不能只靠 referer 或隐藏字段静态值
- 上传路径不能放在 web 可访问目录，最好用随机名 + 存储在
/var/uploads/类非公开路径
真正容易被忽略的是：验证和过滤必须按「接收 → 过滤 → 验证 → 存储 → 输出转义」顺序刚性执行，中间任何一环跳过或颠倒，都会让前面的工作归零。
