mysqli_real_escape_string在php 8.3+中仍存在但不推荐单独用于防sql注入，因其仅转义字符串特殊字符，无法防护数字型注入、like通配符、字符集错配等问题；应改用预处理语句实现代码与数据隔离。
mysqli_real_escape_string()调用是否还有效
PHP 8.0 没删这个函数，但它现在要求第一个参数必须是有效的 mysqli 连接对象——如果连接失败、未初始化或被提前 mysqli_close()，调用就会直接报 Fatal error: Uncaught ValueError: mysqli_real_escape_string(): Argument #1 ($mysql) must be of type mysqli, null given。
常见失效场景：
- 旧代码里把连接句柄存在全局变量或静态属性中，但没做存活校验，升级后连接中断时仍传
null进去 - 用了
mysqli_connect()但没检查返回值，连接失败时得到false，后续当对象传给mysqli_real_escape_string() - 在长生命周期脚本（如 CLI 或常驻进程）中复用连接，超时断开后未重连就继续调用
实操建议：
- 所有
mysqli_real_escape_string($conn, $str)前加if (!$conn instanceof mysqli) { throw new RuntimeException('DB connection lost'); } - 别再依赖“连接总在那儿”，改用封装好的安全方法，例如：
function safe_escape($conn, $str) { return $conn instanceof mysqli ? mysqli_real_escape_string($conn, $str) : addslashes($str); } - 更推荐直接弃用：改用预处理语句（
mysqli_prepare()+mysqli_stmt_bind_param()），它从根源上绕过字符串转义逻辑
mysql_* 函数残留是否引发致命错误
PHP 8.0 已物理删除整个 mysql_* 函数族，包括 mysql_real_escape_string()。只要代码里还存在任何 mysql_* 调用，不管是否执行到，只要被 PHP 解析器读到（比如在条件分支里），就会立即报 Fatal error: Uncaught Error: Call to undefined function mysql_real_escape_string()。
容易漏掉的地方：
- 第三方插件或老旧 CMS 的模板文件（如
.php后缀的 HTML 混写文件）里藏着mysql_real_escape_string() - 自定义的
db_helper.php或functions.php中封装了兼容层，内部仍调用mysql_* - 注释里写着
// mysql_real_escape_string() is deprecated—— 这类注释不会报错，但说明项目曾重度依赖它，得顺藤摸瓜查实际调用
实操建议：
- 全局搜索：
grep -r "mysql_real_escape_string\|mysql_escape_string" . --include="*.php" - 重点扫描：
./plugins/、./includes/、./themes/*/template.php等非主框架目录 - 发现即删或替换：统一改为
mysqli_real_escape_string($conn, $str)或（更优）改用预处理
SQL注入防御逻辑是否被类型变更破坏
PHP 8.0 把很多“隐式兜底”行为变成了硬性拦截，导致旧防御链断裂。典型例子：用 intval() 或 (int) 强转用户输入后拼进 SQL，看似安全，但若原始输入是 null 或布尔值，PHP 8 会直接报错，而不是返回 0。
例如这段旧代码在 PHP 7.4 可跑，在 8.0 会崩：
$id = $_GET['id'] ?? null; $sql = "SELECT * FROM users WHERE id = " . (int)$id;
因为 (int) null 在 PHP 8.0 触发 TypeError，根本走不到 SQL 拼接那步。
实操建议：
- 所有用于 SQL 拼接的变量，先做类型归一化：
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT) ?: 0; - 拒绝裸用
(int)或intval()处理可能为null的输入；用filter_var()显式声明意图 - 检查所有
WHERE id = ?类型的查询，确认占位符绑定前已做过有效性判断，而不是靠类型转换“碰运气”
PDO::quote() 是否因扩展未重编译而静默失效
PDO::quote() 本身没被移除，但它的底层依赖 PDO MySQL 驱动。PHP 8.0 的 ABI 不兼容 PHP 7.4，若你从旧环境复制了 pdo_mysql.so 或宝塔没重装扩展，该方法可能返回空字符串、false，甚至不报错直接放行恶意字符。
验证方式：
- 运行
php --ri pdo_mysql，确认输出里有PDO Driver for MySQL => enabled，且版本号 ≥ 8.0 - 手动测试：
$pdo = new PDO("mysql:host=127.0.0.1;dbname=test", "root", ""); var_dump($pdo->quote("'; DROP TABLE users; --")); // 应返回带引号的转义字符串，不是空或 false - 检查
/www/server/php/80/lib/php/extensions/no-debug-non-zts-20200930/pdo_mysql.so是否存在（路径中的20200930是 PHP 8.0 ABI ID）
关键点：扩展名存在 ≠ 功能可用。哪怕 php -m 显示 pdo_mysql，若 ABI 不匹配，quote() 就可能返回异常结果，且无明确报错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
