PHP 数组构建看似正常，但在处理第 10 个字段时突然触发 Unexpected end of JSON input 错误，根源常是字符串中混入不可见的 Unicode 字符（如 em-dash、en-dash、零宽空格等），导致后续 JSON 编码/传输阶段崩溃。
php 数组构建看似正常，但在处理第 10 个字段时突然触发 `unexpected end of json input` 错误，根源常是字符串中混入不可见的 unicode 字符（如 em-dash、en-dash、零宽空格等），导致后续 json 编码/传输阶段崩溃。
在实际开发中，array_push() 本身不会因“第 10 次调用”而失败——它不关心索引或循环次数。题中描述的“前 9 次成功、第 10 次报错”，本质是错误发生在后续环节：当 $pot_list 被 json_encode() 输出（例如作为 API 响应）时，其中某条数据（恰好对应 q10 构造的 $pot_info）包含非法 UTF-8 字符，致使 JSON 编码中断，前端收到截断或乱码响应，最终抛出 Unexpected end of JSON input。
问题答案已明确指出：'scale_def' => "Scale Definition here." 这一字符串中，实际嵌入了 em-dash（—，U+2014） ——一种常见于 Word 或富文本编辑器的长破折号，外观类似 -，但字节长度为 3（UTF-8 编码），且若被错误截断或未正确声明编码，会破坏 JSON 结构完整性。
✅ 正确做法：在构造数组前清理敏感字段中的不可见字符：
function sanitize_utf8_string($str) {
// 移除控制字符、零宽空格、软连字符、各类破折号（可选保留常规短横线）
$clean = preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F\x80-\x9F\u{200B}-\u{200F}\u{202A}-\u{202E}\u{2060}\u{FEFF}]/u', '', $str);
// 可选：将 em-dash（—）、en-dash（–）替换为 ASCII 短横线（-）
$clean = str_replace(["\u{2014}", "\u{2013}"], '-', $clean);
return trim($clean);
}
// 使用示例（替换原 scale_def 赋值）
$scale_def = "Scale Definition here. — Important note!"; // 含 em-dash
$pot_info = [
'id' => '10',
'category_title' => 'INTRAPERSONAL/INTERPERSONAL',
'scale' => $row['q10'],
'scale_def' => sanitize_utf8_string($scale_def) // ✅ 主动净化
];
array_push($pot_list, $pot_info);⚠️ 注意事项：
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖肉眼识别：em-dash（—）与连字符（-）在多数字体中几乎无法区分，需用编辑器「显示不可见字符」功能或 bin2hex() 检查；
- 验证 JSON 安全性：在 json_encode() 后检查返回值，避免静默失败：
$json = json_encode($pot_list, JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE); if ($json === false) { error_log('JSON encode failed: ' . json_last_error_msg()); http_response_code(500); exit; } echo $json; - 数据库层预防：确保 MySQL 连接、表、字段均使用 utf8mb4 字符集，并在 PDO/MySQLi 初始化时显式设置 charset=utf8mb4；
- 开发习惯：所有用户输入或富文本粘贴内容，在存入数组/JSON 前必须经过标准化清洗，而非仅依赖“看起来一样”。
总结：看似随机的“第 N 次失败”，往往是数据污染的信号。array_push() 是无辜的——真正的敌人藏在字符串深处。建立统一的字符串净化流程，比逐行调试更高效、更可靠。
