不能用字符串拼接写SQL，因为用户输入会直接嵌入语句导致SQL注入，如' OR '1'='1可查出全表；唯一安全做法是PDO预处理+绑定参数，并关闭模拟预处理。
为什么不能用字符串拼接写 SQL
因为用户输入的内容会直接混进 SQL 语句里，PDO 不会帮你识别哪部分是数据、哪部分是代码。比如用户传入 ' OR '1'='1，拼出来就变成 SELECT * FROM users WHERE name = '' OR '1'='1'，整张表全被查出来了。
这种漏洞不是“可能出问题”，而是只要拼接 + 用户输入，就一定存在风险。哪怕你做了 trim() 或 htmlspecialchars()，也没用——那些函数防的是 HTML 注入，不是 SQL 注入。
常见错误现象：
- 页面报错 SQLSTATE[42000]: Syntax error or access violation
- 查询结果异常多或为空，但日志里 SQL 看着“语法没错”
- 后台日志出现 UNION SELECT、information_schema 等可疑关键词
用 PDO::prepare() + bindParam() 是唯一靠谱做法
预处理语句把 SQL 结构和数据彻底分开：先让数据库编译好模板（比如 SELECT * FROM users WHERE id = ?），再把值安全地填进去。数据库知道这个问号只是个占位符，不会当 SQL 代码执行。
实操建议：
- 必须用 prepare() 和 execute() 配合，不能只调 query()
- 占位符只能是 ? 或命名参数如 :name，不能拼进表名、字段名、排序方向（这些得靠白名单校验）
- 绑定类型尽量明确，比如整数用 PDO::PARAM_INT，避免字符串被当成数字解析出错
- 示例：
$stmt = $pdo->prepare("SELECT * FROM users WHERE status = ? AND level > ?");
$stmt->bindParam(1, $status, PDO::PARAM_STR);
$stmt->bindParam(2, $minLevel, PDO::PARAM_INT);
$stmt->execute();
setFetchMode() 和 fetch() 的坑别踩
很多人以为只要用了 prepare() 就万事大吉，结果在取数据时又绕回字符串拼接逻辑里。比如手动拼 "user_" . $id 当缓存 key，或者用 fetch() 结果直接拼 HTML 输出，没过滤 XSS —— 这些跟 SQL 注入无关，但属于同一类信任误判。
关键点：
- fetch() 返回的是原始数据，不是“已消毒”的内容
- setFetchMode(PDO::FETCH_ASSOC) 只影响返回格式，不改变数据安全性
- 如果要动态生成字段名（比如按用户偏好选列），必须提前定义白名单数组，不能直接用 $_GET['field']
- 错误示例：$sql = "SELECT " . $_GET['sort'] . " FROM logs"; —— 这里根本没走 prepare()，完全失效
PDO 构造时的 attr 设置常被忽略
默认情况下，PDO 允许模拟预处理（即 PHP 自己做占位符替换，不发给数据库），这在某些旧版本或特定驱动下会绕过真正的预处理机制，导致漏洞重现。
必须显式关闭：
- 创建 PDO 实例时加 [PDO::ATTR_EMULATE_PREPARES => false]
- 同时建议加上 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，让错误立刻抛出，别静默失败
- 示例：
$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);- 某些 MySQL 版本+PHP 组合下，不关
EMULATE_PREPARES 会导致 LIKE 查询的通配符（%）被转义两次，查不到数据
真正难的不是写对那几行 prepare()，而是所有涉及用户输入的地方——包括 URL 参数、表单字段、HTTP 头、甚至文件名——都得统一用绑定参数或白名单控制。漏掉一个点，前面全白做。
