TP6默认不自动转义$_POST，所谓“自动转义”多为magic_quotes_gpc残留、Nginx配置或前端重复序列化所致；需通过phpinfo()、php://input对比及中间件排查确认来源。
ThinkPHP 6.x 中 POST 参数自动转义是怎么回事
默认情况下，ThinkPHP 6 不会对 $_POST 做任何字符转义或过滤，所谓“自动转义”是早期 ThinkPHP 3/5 版本遗留的误解。TP6 使用的是原生 PHP 的 $_POST 数据，但如果你启用了 app_middleware 中的 CheckRequestCache 或自定义了输入过滤中间件，才可能触发类似行为。
常见误判场景：前端传 {"name": "O'Reilly"}，后端用 $this->request->post('name') 拿到 O'Reilly —— 这通常不是 TP6 干的，而是 PHP 的 magic_quotes_gpc（已废弃）残留，或 Nginx/Apache 配置了额外过滤，也可能是前端重复 JSON.stringify 导致反斜杠叠加。
- 检查 PHP 配置：
phpinfo()确认magic_quotes_gpc为Off - 查看 Nginx 配置中是否含
mod_security或自定义rewrite规则对请求体做了处理 - 用
file_get_contents('php://input')直接读原始请求体，对比$this->request->post()输出，确认差异来源
手动处理 POST 字符转义（如需兼容旧逻辑）
如果你确实需要对 POST 参数做统一转义（例如适配老系统、防止 SQL 注入兜底），不建议全局修改 $_POST，而应在业务层按需处理。TP6 推荐方式是使用 think acadeRequest 提供的过滤机制：
// 在控制器方法中
$name = $this->request->post('name', '', 'htmlspecialchars'); // 自动 HTML 转义
$content = $this->request->post('content', '', 'addslashes'); // 类似旧版 addslashes 行为
-
addslashes仅对'、"、、 - 更安全的做法是用 PDO 参数绑定，而非依赖字符串转义
- 若需递归处理整个 POST 数组，可用
array_walk_recursive+htmlspecialchars，但注意跳过已序列化的字段（如 JSON 字符串）
JSON POST 请求体中的中文乱码或转义异常
当前端以 Content-Type: application/json 发送数据时，TP6 默认不会解析 php://input，$this->request->post() 将返回空数组。必须显式调用 $this->request->param() 或手动解析：
立即学习“PHP免费学习笔记（深入）”；
$json = $this->request->getInput(); // TP6.3+
// 或低版本：
$json = file_get_contents('php://input');
$data = json_decode($json, true);
if (json_last_error() !== JSON_ERROR_NONE) {
throw new hinkException('Invalid JSON format');
}
- 确保前端发送的是 UTF-8 编码 JSON，且不含 BOM；否则
json_decode可能失败或中文变乱码 - TP6.2+ 的
$this->request->param()会自动识别 JSON 请求并解析，但前提是Content-Type头严格匹配application/json（不能带;charset=utf-8后缀，否则部分版本会失效） - 如果 JSON 字段值本身含转义（如
"title": "a"b"），json_decode会自动还原，无需再调用stripslashes
为什么不要在中间件里全局 addslashes $_POST
在 AppInit 或中间件中直接遍历并 addslashes($_POST) 是危险操作，会导致后续所有框架逻辑（包括验证器、模型 save、日志记录等）拿到已被污染的数据。
- 模型写入时若再用 PDO 绑定，相当于双重转义，存库变成
O\'Reilly - 验证器规则如
require|alphaNum可能因反斜杠导致校验失败 - 日志中记录的 POST 数据失真，排查问题时误判原始输入
- TP6 的
Request对象内部缓存了原始 POST，修改$_POST不会同步更新其缓存，造成不一致
真正需要统一过滤的场景，应通过验证器的 filter 选项或自定义验证规则实现，作用域可控、可测试、不污染全局状态。
