PHP处理JSON需“解码后验证”与“结构化过滤”协同：先用json_last_error()或JSON_THROW_ON_ERROR校验合法性，再用is_array()、类型检查及filter_var等确保字段符合业务预期。
PHP中处理JSON数组数据时，不能只依赖json_decode()完成转换就认为安全。真正保障数据可靠的关键，在于“解码后验证”与“结构化过滤”两个环节的协同——既要确认JSON本身合法，又要确保其中每个字段符合业务预期。
先确保JSON字符串本身合法且可解析
很多安全问题源于未校验原始输入。即使json_decode()返回null，也不代表能被忽略；它可能是恶意构造的非法字符串、UTF-8乱码或超深嵌套攻击。
- 始终配合
json_last_error()检查解码结果，不只判断是否为null - 对不可信来源（如
php://input、API响应、用户提交）启用JSON_THROW_ON_ERROR标志，让错误显式抛出异常 - 提前用
filter_var($json, FILTER_VALIDATE_REGEXP, ['options' => ['regexp' => '/^\s*(?:\{.*?\}|\[.*?\])\s*$/s']])做轻量级结构预检，快速拦截明显非法格式 - 确认字符编码为UTF-8，非UTF-8字符串（如GBK混入）会触发
JSON_ERROR_UTF8
解码后必须验证数组结构与字段类型
JSON成功转为PHP数组只是第一步。攻击者可能提交合法JSON但篡改字段类型（如把数字ID传成字符串）、注入多余字段、或缺失必填项。此时需主动验证而非信任结构。
- 使用
is_array()和array_key_exists()确认顶层结构及关键键存在 - 对每个字段单独校验类型：
is_string($data['name'])、is_int($data['id'])、filter_var($data['email'], FILTER_VALIDATE_EMAIL) - 对数值类字段额外限制范围，例如
isset($data['age']) && is_int($data['age']) && $data['age'] >= 0 && $data['age'] - 用
array_filter($data, 'is_scalar')剔除资源、闭包等不可序列化/不安全类型（尤其当后续要再次json_encode()回传时）
结合过滤器清理敏感字段内容
即使字段类型正确，其内容仍可能存在XSS、SQL注入风险或格式污染。PHP过滤器在此阶段比手动strip_tags()或htmlspecialchars()更可控、可组合。
立即学习“PHP免费学习笔记（深入）”；
- 对用户输入类字段（如
title、content）使用filter_var($data['title'], FILTER_SANITIZE_FULL_SPECIAL_CHARS)转义HTML特殊字符 - 对URL字段用
filter_var($data['url'], FILTER_VALIDATE_URL)验证并可选FILTER_FLAG_PATH_REQUIRED - 对数字ID或金额，优先用
filter_var($data['id'], FILTER_VALIDATE_INT)或FILTER_VALIDATE_FLOAT，失败则拒绝处理 - 避免直接使用
FILTER_UNSAFE_RAW，除非你明确知道该字段已由前端双重净化且服务端无渲染逻辑
应对深层嵌套与大整数等边界场景
真实业务JSON常含多层嵌套或超长ID（如微信OpenID、区块链地址），这些容易绕过基础验证，引发静默失败或精度丢失。
- 设置
json_decode($json, true, 1024, JSON_BIGINT_AS_STRING)，防止64位整数被截断为float导致精度误差 - 通过
ini_set('max_nesting_level', 1024)提升嵌套深度限制，并在解码后用count($data, COUNT_RECURSIVE)粗略估算数据规模，防内存耗尽 - 对嵌套数组逐层验证，例如
isset($data['items']) && is_array($data['items'])之后，再遍历$data['items']中每个元素执行字段校验 - 敏感操作（如数据库写入）前，用
array_keys($data)比对白名单，移除未知字段，防止“越权字段注入”
