上传成功却报“数据格式错误”是因为Layui在JSON.parse前未清洗响应体中的BOM（\uFEFF）、控制符或多余空白，导致解析失败；需后端主动清除或前端容错解析。
为什么上传成功却报“数据格式错误”
根本不是编码问题，而是 layui 在 json.parse() 前没做字符清洗——只要响应体开头带 bom（\ufeff）、中间有不可见控制符、或末尾多空格，就会解析失败，触发 data-format-error。浏览器 network 面板看到的“正常 json”，可能实际是 {"code":0,"msg":"ok"} 这种肉眼难辨的乱码。
检查响应体是否含 BOM 或非法字符
打开浏览器 Network → 找到上传请求 → 点 Response 标签页 → 右键“Save response as…”保存为 .txt → 用 VS Code 或 Notepad++ 以 UTF-8 with BOM / ANSI 模式反复切换查看。常见现象：
- 文件开头出现
（BOM 的 ASCII 表示） - 响应末尾多出换行、
\r\n或零宽空格\u200B - PHP 中
echo前有空白、或开启了output_buffering - Java 中
@ResponseBody方法被 Filter 或 Interceptor 注入了 HTML 注释
后端强制清除 BOM 和空白的实操方式
不依赖框架自动处理，直接在返回前做净化：
- PHP：用
trim(mb_convert_encoding($json, 'UTF-8', 'UTF-8'))+str_replace("\xEF\xBB\xBF", '', $json) - Node.js（Express）：
res.json()替换为res.set('Content-Type', 'application/json; charset=utf-8').send(JSON.stringify(obj).replace(/^\uFEFF/, '').trim()) - Java（Spring Boot）：在 Controller 返回前加
new String(json.getBytes(StandardCharsets.UTF_8)).trim()，或用@ControllerAdvice统一过滤响应体
关键点：res.json() 在 Express 中默认不 trim；@ResponseBody 在 Spring 中不自动 strip BOM —— 必须手动干预。
前端加一层容错解析（临时兜底）
如果后端短期无法改，可在 done 回调前拦截原始响应：
layui.upload.render({
elem: '#test',
url: '/upload',
done: function(res, index, upload) {
// 不要直接用 res，先尝试清洗
let raw = upload.config.xhr.responseText;
try {
// 移除 BOM、空白、控制字符
raw = raw.replace(/^\uFEFF/, '').trim().replace(/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/g, '');
res = JSON.parse(raw);
} catch(e) {
console.error('清洗后仍解析失败:', raw);
return;
}
// 后续逻辑...
}
});
注意：upload.config.xhr 是原生 XHR 对象，responseText 是未解析的原始字符串 —— 这是唯一能拿到“乱码源”的地方。别试图在 before 或 error 里修，时机已过。
真正麻烦的不是 BOM，而是某些老系统模板引擎（如 FreeMarker）静默注入的不可见字符，它们不会出现在开发者工具的 Response 预览区，只在“Raw”或保存文件后暴露。每次改完后端，务必用 curl -s http://your-api/upload | hexdump -C 看开头字节。
