不会，addslashes()只转义ASCII范围内的'、"、和 ，对UTF-8中文完全透明；但非SQL注入防护方案，递归处理应仅针对string类型、避免重复转义，并优先使用预处理语句。
PHP 递归函数里 addslashes() 会破坏 UTF-8 中文吗？
不会，addslashes() 只转义 ASCII 范围内的 '、"、 和 ，对 UTF-8 多字节字符（如中文）完全透明。但要注意：它不处理 HTML 实体或 URL 编码，也不是防 SQL 注入的正确方案——仅适用于极简场景（比如写入文件前临时转义单双引号）。
常见误用是把它当万能“防注入”工具，结果在 MySQLi/PDO 中反而造成重复转义，查不到数据。
怎么安全地递归转义多维数组里的特殊字符？
核心原则：明确目标字符、避免重复处理、保留原始结构。不要直接套用 array_walk_recursive()，它会扁平化键名，丢失嵌套层级。
- 用自定义递归函数，保持数组键和结构不变
- 只对
string类型值做转义，跳过int、bool、null、array - 判断是否已转义过（比如值里已有
\或'），避免层层叠加 - 若目标是 SQL 插入，优先改用
$pdo->quote()或预处理语句，而非手动转义
示例：
立即学习“PHP免费学习笔记（深入）”；
function escape_array_recursive($arr) {
foreach ($arr as $key => $value) {
if (is_string($value)) {
// 避免重复转义：只对未被转义的单引号/反斜杠处理
if (!preg_match('/^\\|\\'|\\"/', $value)) {
$arr[$key] = addslashes($value);
}
} elseif (is_array($value)) {
$arr[$key] = escape_array_recursive($value);
}
}
return $arr;
}
为什么 htmlentities() 不该在递归里无条件调用？
因为 htmlentities() 是面向输出的编码，不是数据存储转义。在数组入库前就调用，会导致数据库存的是 这类实体，后续再输出时可能双重编码成 <code>。
更关键的是：它默认只处理 ASCII，UTF-8 中文需显式传 UTF-8 第二参数，否则返回空字符串 —— 这个坑很多人踩过。
- 错误写法：
htmlentities($value)→ 中文变空 - 正确写法：
htmlentities($value, ENT_QUOTES, 'UTF-8') - 但依然不推荐在递归中统一调用：JSON 接口、API 返回、日志记录都不需要 HTML 实体
遇到嵌套对象或资源类型怎么办？
标准递归函数通常只处理 array 和 string，遇到 stdClass、SimpleXMLElement 或 resource 会报错或跳过。
如果必须支持对象，先用 is_object($v) && method_exists($v, '__toString') 判断能否转字符串；对不可转的对象，建议抛异常或跳过，而不是静默忽略 —— 否则调试时根本不知道哪层丢了数据。
资源类型（如 mysqli_result）不能被递归处理，必须提前过滤或转换为数组再进入递归流程。
真正难的不是写递归，而是想清楚：这个转义到底服务于哪个下游环节？是进 MySQL？写入 JSON 文件？还是拼接 JS 字符串？每种场景该转什么、不该转什么，边界一旦模糊，后面全是补丁。
