php 7.0 彻底移除 mysql_* 扩展，必须改用 mysqli 或 pdo；所有查询须强制使用预处理语句防注入，禁用字符串拼接与 escape 类“补丁”，并统一配置 utf8mb4 字符集及最小权限数据库账号。
mysql_* 扩展在 PHP 7.0 中已被彻底移除，任何仍在用 mysql_connect、mysql_query 等函数的项目，不仅存在 SQL 注入风险，而且根本无法在现代 PHP 环境中运行。修复必须分两步走：先升级底层扩展，再重构查询逻辑。
替换过时的 mysql_* 扩展为 mysqli 或 PDO
直接搜索整个项目中的 mysql_connect、mysql_select_db、mysql_query，全部替换成 mysqli 或 PDO 对应调用。注意：mysql_* 不支持参数化查询，这是硬伤，光靠加 mysql_real_escape_string 不能解决问题。
推荐优先选 PDO，因为它的预处理接口统一，切换数据库更方便；若项目已大量使用 mysqli，可沿用其面向对象风格（new mysqli()），但必须弃用过程式写法。
-
PDO连接示例：$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass, [PDO::ATTR_EMULATE_PREPARES => false]); - 关键配置项
PDO::ATTR_EMULATE_PREPARES => false必须显式关闭，否则 PDO 会退化为客户端模拟预处理，失去防注入能力 - 不要用
mysqli_real_escape_string+ 字符串拼接来“打补丁”，它对多字节编码、宽字符等场景有绕过风险
所有用户输入必须走 prepare + bind_param 或 execute 参数绑定
哪怕只有一处漏掉，整套防护就形同虚设。重点不是“有没有过滤”，而是“有没有把数据和 SQL 结构完全隔离”。
常见错误是以为用了 mysqli_prepare 就安全了，结果仍用 sprintf 拼接表名或字段名——这些无法参数化，必须白名单校验。
- 值（value）一律用占位符：
$stmt = $mysqli->prepare("SELECT * FROM users WHERE id = ? AND status = ?"); $stmt->bind_param("is", $id, $status); - 表名、字段名、ORDER BY 条件等动态结构，不能进参数绑定，需严格匹配白名单：
in_array($sort_field, ['name', 'created_at'], true) - 数字型 ID 等看似安全的输入，也不能直接拼进 SQL，比如
"WHERE id = $id"—— 攻击者可能传入1 OR 1=1，字符串上下文里照样生效
检查并收紧数据库账号权限
即使代码层修复完成，如果应用数据库账号仍拥有 DROP、CREATE、LOAD_FILE 等高危权限，攻击者一旦找到其他漏洞（如二次注入、日志注入），仍可能提权。
- 生产环境账号只授予必要权限：
SELECT、INSERT、UPDATE、DELETE，按业务模块拆分账号更佳 - 禁用
FILE权限，防止通过SELECT ... INTO OUTFILE写 Webshell - 避免使用 root 或同等级账号，不设置空密码
别忽略字符集与连接层的隐性漏洞
MySQL 连接默认字符集不一致，会导致 SET NAMES gbk 后，%A1%AA 这类双字节 payload 绕过 mysqli_real_escape_string 的转义——但这个问题在真正启用服务端预处理（PDO::ATTR_EMULATE_PREPARES = false）后自然消失。
- 确保连接初始化时指定字符集：
$pdo = new PDO("mysql:host=localhost;charset=utf8mb4", ...) - 对应数据库、表、字段也统一设为
utf8mb4_unicode_ci，避免隐式转换引发边界问题 - 不要依赖
mysql_set_charset这类已废弃函数，它在mysqli中对应mysqli_set_charset，且必须在连接后立即调用
真实修复中最容易被跳过的，是那些藏在分页、排序、导出、统计类 SQL 里的动态字段拼接。它们往往不在主业务流里，测试覆盖弱，但恰好是攻击者最爱挖的盲点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
