htmlspecialchars() 仅防 html xss，对 sql 注入无效；预处理语句是唯一可靠的 sql 防御方案；filter_var() 适用于输入校验但需配合业务逻辑；文件路径和命令执行需严格过滤用户输入。
PHP 中 htmlspecialchars() 为什么不能替代 SQL 转义
它只防 HTML 输出上下文的 XSS，对数据库查询完全无效。把用户输入直接拼进 SQL 语句，哪怕过了 htmlspecialchars()，照样被 INSERT 或 SELECT 注入打穿。
常见错误现象：页面显示正常（XSS 没了），但后台日志里出现 UNION SELECT password FROM users 这类请求，数据库已被拖库。
- 使用场景：仅用于输出到 HTML 页面前（比如
echo htmlspecialchars($user_input);） - 参数差异：
ENT_QUOTES必须显式传入，否则单引号不转义；UTF-8字符集要明确指定，否则多字节字符可能截断出错 - 性能影响：极低，但别在循环里反复调用同一变量——缓存结果更稳妥
预处理语句（PDO/MySQLi）是唯一靠谱的 SQL 安全方案
不是“推荐”，是 PHP 里目前唯一能系统性阻断 SQL 注入的机制。所有其他函数（mysql_real_escape_string 已废弃、addslashes 有绕过漏洞）都不应再用于生产环境。
常见错误现象：用 prepare() 但把变量拼进 SQL 字符串里，比如 $pdo->prepare("SELECT * FROM user WHERE id = " . $_GET['id']) —— 这跟没用预处理一样危险。
立即学习“PHP免费学习笔记（深入）”；
- 正确写法必须用占位符：
$stmt = $pdo->prepare("SELECT name FROM user WHERE id = ?"); $stmt->execute([$_GET['id']]); - PDO 默认不开启
PDO::ATTR_EMULATE_PREPARES = false，得手动关掉模拟预处理，否则 MySQLi 才真正走服务端预处理 - 批量插入时，
execute()接数组比循环execute()快得多，且安全边界不变
filter_var() 处理输入校验比手写正则更稳
它不是万能过滤器，但对邮箱、URL、整数、IP 等常见类型，内置规则比自己 preg_match() 更少漏判、更兼容 RFC 标准。
常见错误现象：用 filter_var($email, FILTER_VALIDATE_EMAIL) 验证后直接入库，却没注意它不检查长度、不拒绝空格开头、不拦截某些国际域名变体——仍需配合业务逻辑二次判断。
- 邮箱验证后建议加
trim()去首尾空格，filter_var()不做这个 -
FILTER_SANITIZE_STRING已在 PHP 8.1 移除，别再用；替代方案是filter_var($input, FILTER_SANITIZE_SPECIAL_CHARS)（等价于htmlspecialchars()）或按需用strip_tags() - 整数校验优先用
FILTER_VALIDATE_INT+options=['min_range' => 1]，比is_numeric()或(int)强制转换更严格
文件路径和命令执行是隐藏最深的注入点
开发者常盯着 SQL 和 HTML，却让 include($_GET['page'] . '.php') 或 exec('convert ' . $_FILES['img']['tmp_name']) 直接暴露在外部输入上。
常见错误现象：访问 ?page=../../etc/passwd%00 读取系统文件，或上传带空格的文件名触发命令注入。
- 路径拼接前必须用
basename()截取文件名，禁用任何上级目录符号：include __DIR__ . '/templates/' . basename($_GET['page']) . '.php'; - 执行系统命令时，绝对不要拼接用户输入；非用不可就用
escapeshellarg()包裹每个参数，且确认命令本身无漏洞（如ImageMagick的 Ghostscript 解析缺陷） -
open_basedir是服务器层兜底，不能替代代码过滤；disable_functions关掉exec/system后，攻击者可能转向proc_open或create_function
真正难的不是记住几个函数，而是每次拿到用户输入时，下意识问一句：它接下来会进哪个上下文？HTML？SQL？文件系统？Shell？每个上下文有且仅有一个安全出口，混用就是漏洞。
