PDO连接MySQL必须显式设置charset=utf8mb4和PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION，否则90%乱码和静默失败由此产生；还需主动验证连接有效性并分离配置、妥善处理错误。
直接用 PDO 连 MySQL，不设 charset=utf8mb4 和 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，90% 的乱码和静默失败都从这儿来。
DSN 字符串里必须显式写 charset=utf8mb4
MySQL 默认字符集可能是 latin1 或旧版 utf8（实际是 utf8mb3），PHP 插入中文、emoji 或生僻字时会变成 ???。DSN 中的 charset 参数不是可选的“锦上添花”，而是连接初始化阶段就决定客户端编码的关键开关。
-
mysql:host=localhost;dbname=testdb→ 不指定 charset，PHP 用默认编码通信，大概率乱码 -
mysql:host=localhost;dbname=testdb;charset=utf8mb4→ 显式声明，服务端与客户端编码对齐 - 别写
charset=utf8：它不支持 4 字节 UTF-8 字符，utf8mb4才是 MySQL 官方推荐的完整 UTF-8 实现 - host 后不要加端口如
localhost:3307；正确写法是host=localhost;port=3307，否则 PDO 可能解析失败
PDO::ATTR_ERRMODE 必须设为 PDO::ERRMODE_EXCEPTION
默认情况下，PDO 遇到 SQL 错误（比如字段不存在、类型不匹配）只返回 false，不报错也不抛异常——你执行完 query() 或 execute() 却没检查返回值，就等于“以为成功了，其实什么都没干”。
- 不设这个选项：错误被吞掉，调试靠猜，线上问题难复现
- 设为
PDO::ERRMODE_EXCEPTION：所有错误立刻抛出PDOException，try/catch一抓一个准 - 设置时机必须在
new PDO()之后、任何查询之前，且不能晚于第一次调用prepare() - 别只在构造时传选项数组，还要确认
PDO::ATTR_ERRMODE确实被覆盖了（有些框架会重置）
连接后立即验证是否真通，别等查数据才翻车
DSN 写对、扩展开着、用户名密码没错，不代表连接一定能建起来。网络、权限、MySQL wait_timeout、防火墙都可能拦在中间。光看 new PDO() 不报错，不等于连接可用。
- 最简验证：用命令行跑
mysql -h 127.0.0.1 -P 3306 -u testuser -p，能进再说 PHP - PHP 里别依赖“没异常=成功”，加一句
$pdo->query("SELECT 1")->fetchColumn()主动探活 - 如果用容器或远程 host，别写
localhost——它可能走 Unix socket，权限/路径不对；改用127.0.0.1强制走 TCP - 连接失败的典型错误：
SQLSTATE[HY000] [2002] Connection refused（MySQL 没启）、Access denied for user（账号没权限或 host 匹配不上）
配置分离和错误处理不能省
把数据库参数硬编码在 new PDO() 里，上线换环境就得改代码，还容易把密码提交到 Git。而错误信息直接 echo $e->getMessage()，等于把数据库结构、路径甚至密码（如果拼错了）全吐给前端。
- 用户名、密码、host、dbname 全部从
getenv()或配置文件读，例如$dsn = "mysql:host=" . getenv('DB_HOST') . ";dbname=" . getenv('DB_NAME') . ";charset=utf8mb4" -
catch (PDOException $e)里只记录日志（$e->getMessage()+$e->getCode()），绝不输出给用户 - 生产环境禁用
display_errors，避免错误回显暴露敏感信息 - 连接对象不用时设为
null，虽然析构函数会关，但显式释放更可控
字符集、错误模式、连接验证这三件事，漏掉任何一个，都会让后续所有查询处于“看似运行、实则失效”的状态——不是代码写得不够多，而是最前面那几步踩空了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
