php 5.4起magic_quotes_gpc已被移除，7.4废弃、8.0彻底删除get_magic_quotes_gpc()；残留代码导致双重转义，应全局删除相关判断与stripslashes逻辑，改用pdo/mysqli预处理，并一次性清洗历史脏数据。
PHP 5.4.0 起 magic_quotes_gpc 已被彻底移除，任何还在处理它的代码，本质是在维护一个不存在的特性——你遇到的“问题”，几乎肯定是残留逻辑导致的双重转义或数据不一致。
get_magic_quotes_gpc() 报 Deprecated 或 Fatal Error
PHP 7.4 开始该函数被标记为废弃，8.0 完全删除。直接调用 get_magic_quotes_gpc() 会触发 Call to undefined function 错误。
- 不要写兼容函数模拟它（比如返回
false或查ini_get()），因为这会让旧逻辑继续执行，掩盖真正的问题 - 搜索整个项目，删掉所有
if (get_magic_quotes_gpc()) { ... stripslashes(...) ... }这类判断和清理块 - 若必须临时过渡，仅在入口处做一次无条件
stripslashes_deep()（仅当确认历史数据已被魔改过） -
ini_get('magic_quotes_gpc')在 PHP 8+ 返回false，不能当作等效替代；它只是配置项读取，不代表运行时行为
输入数据里多出反斜杠（如 don't 变成 don\'t）
这不是 magic_quotes_gpc 在起作用，而是代码里重复调用了 addslashes() 或未识别已有转义就再次处理。
- 检查所有对
$_POST、$_GET的赋值点，尤其注意封装了“安全过滤”的工具函数 - 数据库写入前，**绝对不要**拼接 SQL 字符串 +
addslashes()；改用PDO::prepare()或mysqli->prepare() - JSON 接口（
file_get_contents('php://input')）、CLI 参数、cURL 回调等完全不受 magic_quotes 影响，但你的“兼容层”可能错误地对它们也做了stripslashes - 用
var_dump(bin2hex($str))查看原始字节，确认是单个（0x5c）还是双\（0x5c 0x5c），后者才是双重转义铁证
升级老系统时数据库里存了带多余反斜杠的数据
迁移后发现用户昵称变成 O'Connor 而不是 O'Connor，说明旧环境曾开启 magic_quotes_gpc，且写入前没做 stripslashes()，或者做了但后续又被加了一次。
- 修复动作应是一次性清洗：写个脚本对目标字段执行
UPDATE table SET name = REPLACE(name, '\'', '''') WHERE name LIKE '%\%';（注意：仅适用于纯单引号场景，复杂情况需 PHP 处理） - 不要在每次读取时动态
stripslashes()—— 这会让缓存、全文索引、API 输出都不可控 - 清洗后，立刻禁用所有残留的
stripslashes_deep()全局处理，否则新数据会变 O''Connor - 确认 MySQL 连接字符集（如
utf8mb4）和 PHP 字符串处理一致，避免多字节字符被截断引发意外转义
最危险的操作，是试图用自动遍历 $_POST 并调用 addslashes() 来“复刻旧环境”。它既不安全（绕过预处理），也不完整（漏掉 php://input），更不可维护（没人能说清哪一层该转哪一层不该转）。真正的分水岭不是“怎么关 magic_quotes”，而是“是否已全面使用参数化查询”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
