能不停机修复SQL注入，前提是漏洞点明确、代码可热替换且数据库连接层支持运行时拦截；最稳妥方式是用参数化查询替换拼接语句，老系统需先升级至mysqli或PDO，再配合入口过滤和缓存清理完成热修复。
能不停机修复 SQL 注入，前提是漏洞点明确、代码可热替换、且数据库连接层支持运行时拦截或重写。现实中，90% 的老系统停机窗口极短，必须在业务运行中完成“打补丁”，而不是等下班再改。
确认漏洞点是否可热修复
不是所有注入点都适合不停机修复。关键看它是否落在可单独 reload 的逻辑层：
-
$_GET或$_POST参数直接拼进mysql_query()的地方，只要文件没被 opcode 缓存锁定（如未启用opcache.validate_timestamps=0），改完 PHP 文件后请求下次进来就能生效 - 若漏洞在编译型语言（如 Java 的
Statement.execute()）或常驻进程（如 Node.js 的express未用nodemon），则必须重启服务——所谓“不停机”只是错觉 - 若使用了 ORM（如 ThinkPHP 的
where()链式调用但传入了原始字符串），需确认该 ORM 版本是否支持运行时切换为参数化模式；老版本（如 TP3.2）不支持，硬切会报错
用参数化查询替换拼接语句（最稳妥）
这是唯一能根除注入风险的热修复方式，无需改表结构或权限，改完即生效：
- 把
$sql = "SELECT * FROM users WHERE id = ".$_GET['id'];改成$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$_GET['id']]); - 若用 MySQLi，对应改用
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ?"); $stmt->bind_param("s", $_POST['username']); $stmt->execute(); - 注意：老项目常用
mysql_*函数（已废弃），必须先升级到mysqli或PDO才能用预处理——这步本身就需要一次轻量级重启（仅 reload PHP-FPM 进程），不是全站停服
临时加过滤层（应急兜底）
当无法立刻改 SQL 逻辑（比如第三方插件源码不可控），可在入口统一拦截可疑输入：
- 在
index.php顶部或框架中间件里加判断：if (preg_match('/(union\s+select|sleep\(|load_file|outfile|into\s+dumpfile)/i', implode('', $_REQUEST))) { http_response_code(403); exit('Access denied'); } - 不要只过滤
union，攻击者会用大小写混淆（UnIoN）、编码绕过（%75%6e%69%6f%6e）或注释符（/**/union/**/select）——正则得带i和s修饰符 - 这种过滤不能替代参数化，只是争取修复时间；过度拦截可能误杀正常搜索词（比如用户真搜 “union select”），上线前务必用真实日志回放验证
为什么不能只靠 WAF 或数据库权限收缩
这两招看似“不用改代码”，但实际掩盖问题而非解决：
- WAF 规则滞后：新型绕过手法（如用
extractvalue()、updatexml()报错注入）往往要等厂商更新规则库，期间漏洞仍裸奔 - 数据库降权治标不治本：即使把应用账号设为只读，攻击者仍可用
SELECT ... INTO OUTFILE写 shell，或通过报错泄露表名、字段名，为后续攻击铺路 - 真正关键的是让恶意输入在到达数据库前就失去“执行语义”——只有参数化查询能做到这点
最易被忽略的一点：修复后必须检查所有缓存层。如果用了 Redis 缓存 SQL 查询结果，旧的恶意 payload 可能已被缓存，导致你改完了代码，用户仍看到注入成功的结果。别忘了清掉相关 key 或加 version 前缀。
