mysql_connect()在PHP 5.5起被标为Deprecated，根本原因是其设计缺失预处理、字符集绑定、连接超时控制等安全机制，易导致SQL注入（如宽字节绕过mysql_real_escape_string）和静默故障，官方停止维护并强制迁移到mysqli或PDO。
mysql_connect() 为什么连 PHP 5.5 都开始报 Deprecated
不是因为“写法老”，而是它从设计上就缺失现代数据库交互必需的安全机制。PHP 官方在 5.5.0 版本打上 Deprecated 标签，本质是宣告：这个扩展已停止维护，不再修复漏洞，也不再适配新 MySQL 协议特性。
常见错误现象包括：Deprecated: mysql_connect(): The mysql extension is deprecated...，但更危险的是——你没看到报错时，SQL 注入可能已经发生。
- 不支持预处理语句（
PDO::prepare()或mysqli_prepare()），所有参数都靠字符串拼接 - 没有内置的字符集绑定机制，
mysql_set_charset()调用时机不对就会绕过编码防护 -
mysql_real_escape_string()依赖当前连接状态，若连接未建立或中断，该函数返回false，但开发者常忽略返回值直接拼 SQL - 无法控制连接超时、读写超时等关键网络参数，容易被慢查询或恶意连接拖垮服务
SQL 注入漏洞如何绕过 mysql_real_escape_string()
很多人以为加了 mysql_real_escape_string() 就安全了，其实不然。该函数只对单字节字符集（如 latin1）可靠；一旦数据库连接使用 utf8mb4，而客户端未显式设置字符集，或调用顺序错乱（比如先执行查询再调用 mysql_set_charset()），就可能出现“宽字节注入”。
典型绕过场景：
立即学习“PHP免费学习笔记（深入）”；
- 数据库配置为
utf8mb4，但脚本里漏掉mysql_set_charset($conn, 'utf8mb4') - 使用
mysql_query("SET NAMES utf8")替代mysql_set_charset()，后者才真正影响mysql_real_escape_string()的行为 - 在多字节编码下，
%df%27这类双字节序列可能被 MySQL 解析为单个字符，导致转义失效
mysqli_connect() 和 PDO::__construct() 的关键安全差异
二者都能解决 mysql_connect() 的根本缺陷，但用法和默认行为不同，选错一样出问题。
-
mysqli_connect()默认不启用严格模式，需手动执行mysqli_query($conn, "SET sql_mode='STRICT_TRANS_TABLES'") - PDO 构造时若不传
PDO::ATTR_EMULATE_PREPARES => false，会退化为模拟预处理，失去防注入保障 - mysqli 支持
MYSQLI_CLIENT_SSL标志直连加密，PDO 则需在 DSN 中显式写sslmode=require（PostgreSQL 风格）或配置PDO::MYSQL_ATTR_SSL_*系列选项 - 两者都要求显式设置字符集：
mysqli_set_charset($conn, 'utf8mb4')或$pdo->exec("SET NAMES utf8mb4")，不能依赖配置文件
遗留系统升级时最容易被忽略的兼容性陷阱
把 mysql_connect() 换成 mysqli_connect() 只是第一步。很多老项目还混着用 mysql_fetch_array() 这类函数，它们不会自动映射到 mysqli 对应版本——必须逐个替换，且注意参数顺序变化。
-
mysql_query($sql, $conn)→mysqli_query($conn, $sql)（参数顺序反转） -
mysql_fetch_assoc($result)→mysqli_fetch_assoc($result)（函数名变长，但无自动别名） -
mysql_error()→mysqli_error($conn)（必须传连接资源，否则返回空） - 所有结果集操作函数（
mysql_num_rows、mysql_data_seek等）都必须显式加mysqli_前缀，且多数要求第一个参数是连接或结果资源
最麻烦的是错误抑制符 @：旧代码里大量 @mysql_query(...)，升级后 @mysqli_query(...) 仍会抑制致命错误，但不会掩盖连接失败这类底层异常，容易让故障静默蔓延。
