PHP 8.5.5 本身不处理数据库连接，错误根源在于连接逻辑、扩展配置或框架层；PDO/MySQLi 扩展启用后版本兼容性无问题，真正导致失败的是 DSN 参数错误、驱动缺失或环境未对齐，且 utf8mb4 必须五层全对齐（服务端、库表字段、DSN、SET NAMES、PHP 环境），缺一即致 emoji 乱码或静默截断。
PHP 8.5.5 本身不处理数据库连接，错误根源几乎都在你写的连接逻辑、扩展配置或框架层。只要 PDO 或 MySQLi 扩展已启用，版本兼容性不是问题；真正导致连接失败的，是参数错、驱动漏、环境没对齐。
DSN 和 options 必须同时设 charset（尤其 utf8mb4）
只在 DSN 里写 charset=utf8mb4 不够，只在 $options 里加 PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4' 也不够——两者缺一，emoji 插入失败、JSON 字段乱码、中文静默截断都可能发生。
-
$dsn = 'mysql:host=127.0.0.1;port=3306;dbname=test;charset=utf8mb4'—— DSN 中必须显式包含charset=utf8mb4 -
$options数组中必须含：PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION（否则错误不抛异常，fetch()返回空数组，调试时毫无线索） - 还要加：
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4'，否则某些字段（如JSON类型）仍可能出问题
Oracle 连接失败常卡在 OCI DSN 格式或初始化参数
ORA-12154 不是网络不通，是 PDO 初始化阶段就崩溃了——OCI 驱动对 DSN 和 params 极其苛刻，漏掉任意一项就直接失败。
- DSN 必须是完整 OCI 形式：
oci:dbname=//127.0.0.1:1521/ORCL;charset=UTF8（注意双斜线、服务名大小写、UTF8不能写成utf8） - params 至少要三项：
PDO::ATTR_CASE => PDO::CASE_NATURAL、PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION、PDO::ATTR_ORACLE_NULLS => PDO::NULL_NATURAL - 如果用 ThinkPHP 8，
Db::connect('oracle')的键名必须和config/database.php中connections数组的键**完全一致**（大小写、下划线、空格全敏感），写成'Oracle'或'oracle_db'都会 fallback 到 default 且无提示
超时与重连必须按场景区分对待
连接超时设太长会拖垮请求，设太短又误判正常抖动；自动重连看似省事，但用错地方反而引发数据不一致。
立即学习“PHP免费学习笔记（深入）”；
- 生产建议连接超时设为
3~10秒，通过 DSN 加connect_timeout=5或 options 加PDO::MYSQL_ATTR_CONNECT_TIMEOUT => 5 - 重连只允许在**非事务内**触发——事务中重连会导致状态丢失，必须直接放弃
- 仅对特定错误码重试：
HY000+2006（MySQL server has gone away）或2013（Lost connection），其他错误（如权限拒绝、表不存在）重试毫无意义
ThinkPHP 8 多库配置别依赖 .env 嵌套键
TP8 读 .env 是扁平替换，不支持 DB_ORACLE_HOST 这类嵌套键。一旦开了 .env，你手动写的 'oracle' => [] 很可能被覆盖成默认 MySQL 配置，而且不报错。
- 最稳做法：在
config/database.php中完全手写connections数组，所有值硬编码，不调任何env() - 如果非要保留
.env，就把每个库拆成独立块，比如'oracle' => ['hostname' => '127.0.0.1']，且所有字段都不走env() - 检查 MySQL 服务是否运行：
systemctl status mysql；确认 PHP 已启用扩展：php -m | grep pdo_mysql
最容易被忽略的是五层 utf8mb4 对齐：MySQL 服务端、库/表/字段字符集、连接层 DSN、运行时 SET NAMES、PHP 环境（如 mbstring 设置）。其中任意一层是 utf8 而非 utf8mb4，emoji 就会出问题，且错误表现极其隐蔽——插入成功但查出来是问号或空字符串。
