PHP PDO连接需显式启用异常模式、指定utf8mb4字符集、禁用模拟预处理，并确保服务端、表结构与连接层编码一致，否则易导致静默失败、乱码或注入风险。
PHP数据库连接不是“必须”用PDO，但不用PDO就大概率踩坑——尤其是SQL注入、错误静默、跨库迁移失败这三类问题。
为什么new PDO()不报错却查不到数据
这是新手最常卡住的点：连接代码跑通了，new PDO()没抛异常，但后续$pdo->query()返回false或空结果。根本原因在于PDO默认错误模式是PDO::ERRMODE_SILENT，它不会中断执行，只把错误存进$pdo->errorInfo()里。
- 必须显式设置
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则所有错误都得手动检查errorInfo() - 连接字符串里的
dbname拼错、库不存在、字符集不支持（比如写utf8而非utf8mb4），都会导致后续查询无声失败 - 如果用变量拼接DSN，确保
$host、$db等变量已定义且非空，否则"mysql:host=;dbname="这种无效DSN也能过构造函数
PDO::ATTR_EMULATE_PREPARES => false到底要不要设
这个选项控制预处理语句是否由PHP模拟执行，而不是交由数据库原生处理。设为false是防SQL注入的关键防线，但并非所有场景都能开。
- MySQL 5.7以下版本、某些国产数据库（如达梦早期驱动）不完全支持原生预处理，设
false会导致prepare()直接失败 - 若必须兼容旧环境，可先尝试
false，捕获PDOException后回退到true，但要清楚这意味着部分边界输入仍可能被绕过 - PHP 8+ + MySQLi 8.0+环境下，默认已是
false，但显式声明更稳妥，避免依赖隐式行为
字符集错配导致中文变问号或乱码
只在DSN里写charset=utf8mb4不够，MySQL服务端、表结构、连接层三者必须一致，否则INSERT和SELECT会悄悄丢数据。
- DSN中
charset=utf8mb4仅影响连接层，不改变已存在的表编码；建表时仍需显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 若MySQL配置文件（
my.cnf）中collation-server仍是latin1_swedish_ci，即使DSN写了utf8mb4，新连接也可能降级为latin1 - 调试时用
$pdo->query("SHOW VARIABLES LIKE 'character_set%';")->fetchAll()确认实际生效的字符集，别只信DSN
真正容易被忽略的是：PDO实例一旦创建，其charset参数就固化在连接里，后续执行SET NAMES无法覆盖DSN中指定的字符集——这意味着你不能靠运行时SQL去“修复”DSN写错的编码。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
