能，但仅当连接层字符集配置错误时才会触发；必须在DSN中明确声明charset=utf8mb4并禁用模拟预处理，UTF8MB4是唯一被证实免疫宽字节注入的字符集。
宽字节注入在 PHP 8 + PDO 下还能触发吗？
能，但仅当连接层字符集配置错误时才会复活——不是 PDO 写法问题，而是 charset 没对齐。UTF8MB4 是当前唯一被证实免疫宽字节注入的字符集，而 GBK/GB2312 等双字节编码下，%df%27 这类组合仍可绕过转义逻辑，让单引号逃逸。PHP 8.2+ 默认不启用任何字符集兼容降级，所以漏洞根源几乎全在开发者手动写错连接参数。
- 必须把
charset=utf8mb4明确写进 DSN，不能靠$pdo->exec("SET NAMES utf8")补救 - 数据库表、字段、连接池（如用 PDO + MySQLi 混合部署）也得统一为
utf8mb4_unicode_ci -
mysql_set_charset()或旧式SET NAMES在连接建立后执行，已无法影响预处理语句的解析阶段
PDO 连接字符串里 charset 写错的典型表现
错误示例：mysql:host=localhost;dbname=test —— 缺少 charset，MySQL 会按服务器默认（可能是 latin1 或 gbk）建连，PDO 预处理照样执行，但底层驱动可能把 %df%27 当作一个合法字符，导致 bindParam 后的值被“吃掉半个字节”，单引号裸奔进 SQL。
正确写法必须带完整声明：
$dsn = 'mysql:host=localhost;dbname=test;charset=utf8mb4';
且需配合：
-
PDO::ATTR_EMULATE_PREPARES => false（禁用模拟预处理） -
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION（暴露底层错误，便于发现 charset 不匹配报错）
如果连接后执行 $pdo->getAttribute(PDO::ATTR_CLIENT_VERSION) 返回 mysqlnd 8.2.33，但 SHOW VARIABLES LIKE 'character_set%' 显示 character_set_client 是 gbk，说明 DSN 里的 charset 被忽略了——常见于使用了旧版 MySQL 客户端库或中间件劫持连接。
为什么 setAttribute('charset') 不起作用？
$pdo->setAttribute(PDO::MYSQL_ATTR_INIT_COMMAND, "SET NAMES utf8mb4") 是无效的——这个属性只在连接初始化时执行命令，但不改变连接的字符集协商结果。真正决定宽字节是否生效的是 TCP 握手阶段客户端声明的字符集，它由 DSN 中的 charset= 参数驱动。
更隐蔽的问题：某些云数据库代理（如阿里云 RDS Proxy、腾讯云 CDB Proxy）会忽略客户端传入的 charset，强制使用自己的会话设置。此时必须在代理控制台显式配置「默认字符集」为 utf8mb4，否则即使 DSN 写对了也没用。
LIKE 查询中通配符怎么防？
LIKE 是少数需要在 PHP 层手动处理通配符的场景，因为占位符绑定后，% 和 _ 会被当成普通字符，无法实现模糊匹配。
正确做法是：
- 先用
str_replace对用户输入做转义：$search = str_replace(['%', '_'], ['%', '_'], $_GET['q']); - 再拼接通配符：
$stmt = $pdo->prepare("SELECT * FROM posts WHERE title LIKE CONCAT('%', :q, '%') ESCAPE '\'"); - 最后绑定：
$stmt->execute(['q' => $search]);
注意：不要用 bindValue 绑定含 % 的字符串，那会把 % 当成字面量；也不要自己拼 "%{$search}%"，那等于开门揖盗。
真正的难点不在语法，而在业务逻辑是否允许用户自由输入通配符——如果搜索框本就不该支持模糊语法，那就该在前端禁用 % 输入，后端直接校验 ctype_alnum($_GET['q']) 或正则限制。安全边界越早划清，后面越不容易翻车。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
