17370845950

mysql_connect() 在 PHP 7.0+ 中已被彻底移除，必须改用 mysqli 或 PDO；需显式设置 utf8mb4 字符集并使用预处理语句防止 SQL 注入。

mysql_connect() 已被彻底移除，PHP 7.0+ 无法使用

PHP 7.0 起，mysql_* 系列函数（如 mysql_connect()、mysql_query()）已被完全删除，不是“不推荐”，而是**根本不存在**。如果你在 PHP 7.x 或 8.x 环境下看到 Fatal error: Uncaught Error: Call to undefined function mysql_connect()，这就是原因。

这不是配置问题，也不是 extension 没开启——它连源码里都没了。强行降级到 PHP 5.6 并非可行方案，该版本早已停止安全更新，生产环境严禁使用。

替代方案只有两个：mysqli 或 PDO

必须改用现代扩展。两者都支持面向对象和过程式调用，但行为细节差异明显：

• mysqli 是 MySQL 官方维护的专用扩展，语法更贴近老 mysql_* 风格，迁移成本略低；
• PDO 是通用数据库抽象层，支持 MySQL、PostgreSQL、SQLite 等多种驱动，参数绑定更安全，是长期项目首选。

示例对比（连接本地 test 库）：

// mysqli 过程式
$conn = mysqli_connect('localhost', 'root', 'pass', 'test');
if (!$conn) die('连接失败：' . mysqli_error($conn));
// PDO（推荐用 try/catch + 异常模式）
try {
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', 'root', 'pass', [
PDO::ATTR_
ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
]);
} catch (PDOException $e) {
die('连接失败：' . $e->getMessage());
}

字符集必须显式声明，否则中文乱码大概率发生

老 mysql_* 扩展默认不设字符集，靠 MySQL 服务端配置兜底，极易出错。新扩展必须主动指定：

• mysqli：连接后立即执行 mysqli_set_charset($conn, 'utf8mb4')，或在 DSN 中加 ;charset=utf8mb4（仅限面向对象方式）；
• PDO：必须在 DSN 中写明 charset=utf8mb4，且不能只写 utf8（MySQL 的 utf8 实际是 utf8mb3，不支持 emoji）；
• 同时确认 MySQL 服务端 character_set_server 和库/表的 COLLATE 也设为 utf8mb4_unicode_ci 级别。

查询语句不能再直接拼接变量，SQL 注入风险极高

老写法 "SELECT * FROM user WHERE id = " . $_GET['id'] 在新扩展中依然能运行，但等于裸奔。必须用预处理：

• mysqli：用 mysqli_prepare() + mysqli_stmt_bind_param()；
• PDO：用 prepare() + execute()，支持命名参数（:id）和问号占位符；
• 即使只是整数 ID，也别信“过滤 intval 就安全”——类型绕过、逻辑漏洞仍存在，预处理是唯一可靠路径。

老代码里满屏的 mysql_real_escape_string() 全部删掉，它对新扩展无效，且本身防不住所有注入场景。

真正卡住人的往往不是语法转换，而是隐性依赖：比如某些老 CMS 的数据库类封装了 mysql_* 调用，直接替换函数名会崩；或者错误处理逻辑硬编码了 mysql_error() 返回格式。这类情况必须逐层检查调用链，不能只改入口连接代码。