PHP 7.4+ 已彻底移除 magic_quotes_gpc，不存在该配置项；需删除所有 get_magic_quotes_gpc() 调用及兼容逻辑，并改用 filter_input() 和预处理语句确保安全。
PHP 7.4+ 已彻底移除 magic_quotes_gpc，别再试图“关闭”它
魔术引号（magic_quotes_gpc）在 PHP 5.4.0 被标记为 deprecated，PHP 7.0 正式删除，7.4 及以后版本根本不存在这个配置项。如果你在 php.ini 里还找 magic_quotes_gpc = On 或试图用 set_magic_quotes_runtime() 关闭它——那说明你正在维护一段非常老的代码，或者误读了错误提示。
常见误判场景：
- 看到报错含
magic_quotes字样，其实是旧文档/框架残留注释或开发者手动调用已废弃函数 - 迁移老项目时，发现输入数据多了一层反斜杠（如
don't），误以为是 magic quotes 生效，实则是代码里重复调用了addslashes()或未适配get_magic_quotes_gpc()的兼容逻辑
如何安全移除遗留的 magic_quotes 兼容代码
老项目常有类似这样的防御性代码：
if (get_magic_quotes_gpc()) {
$_GET = array_map('stripslashes', $_GET);
$_POST = array_map('stripslashes', $_POST);
$_COOKIE = array_map('stripslashes', $_COOKIE);
}
这段代码在 PHP 5.4+ 会触发 Deprecated: Function get_magic_quotes_gpc() is deprecated；在 PHP 7+ 直接报 Fatal error: Uncaught Error: Call to undefined function get_magic_quotes_gpc()。
立即学习“PHP免费学习笔记（深入）”；
正确做法是：直接删掉整段逻辑，并检查后续是否依赖“已被 stripslashes 的数据”。更稳妥的方式是全局统一过滤入口，例如：
- 确认所有外部输入（
$_GET、$_POST等）不再被自动转义 - 改用
filter_input()显式过滤，比如filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT) - 数据库写入前，统一使用预处理语句（PDO/MySQLi），而非拼接 SQL + 手动
addslashes()
为什么不能“模拟” magic_quotes_gpc 行为
有人想通过自动遍历 $_GET/$_POST 并对字符串调用 addslashes() 来“复刻”旧环境行为——这极其危险：
- 现代框架（Laravel、Symfony）和 CMS（WordPress 5.0+、Drupal 8+）默认不依赖该机制，模拟反而导致双重转义（如
O'Reilly→O\'Reilly） -
addslashes()不等价于原 magic_quotes_gpc：它不处理 null 字节，也不覆盖所有注入向量，且对多字节编码（如 UTF-8）不可靠 - JSON 请求体（
file_get_contents('php://input')）、API 接口、CLI 参数完全不受影响，模拟逻辑极易遗漏
真正需要兼容的，不是“让新 PHP 像旧 PHP”，而是让旧业务逻辑适应无转义的原始输入。
检查和修复的关键点
运行以下代码快速定位风险点：
var_dump(function_exists('get_magic_quotes_gpc'));
// 输出 bool(false) 即表示该函数不存在（PHP 7+）
// 搜索项目中是否还存在：
// get_magic_quotes_gpc()
// set_magic_quotes_runtime()
// addslashes() 直接用于 SQL 拼接
// mysql_real_escape_string()（已废弃）
重点排查位置：
- 全局初始化文件（如
init.php、common.php） - 旧版 CMS 插件或第三方库（特别是 2012 年前的 PHP 类库）
- 自定义的表单处理函数，尤其是带
if (get_magic_quotes_gpc())分支的
最易被忽略的是：有些代码把 stripslashes() 写在了数据库查询之后，而不是输入接收时，导致本不该处理的数据被误删反斜杠。
