1. 这个“Bad string”报错根本不是Postman的问题刚接手一个老项目时我打开Postman点下Send界面右上角突然弹出一行红字Bad string。没有堆栈、没有行号、没有上下文连错误图标都只是个干瘪的感叹号。我第一反应是——这玩意儿是不是拼错了查文档、翻社区、重装Postman、换版本、清缓存……折腾两小时它还是稳稳地蹲在那儿像一句冷笑话。后来我才明白这个报错压根就不是Postman抛出来的。它不来自Postman的UI层也不出自它的网络请求模块而是Postman在解析响应体response body时被JSON解析器拦下的一个底层语法错误提示。准确说是Postman内嵌的json5解析器用于支持JSONC注释和宽松语法在尝试把服务器返回的内容当作JSON处理时发现字符串字段里混进了非法字符——比如未转义的换行符、裸露的控制字符、UTF-8 BOM头、或者更隐蔽的零宽空格U200B。而Postman为了“友好”没把原始SyntaxError堆栈打出来只甩给你四个字“Bad string”。这个标题里的“成功解决”背后其实是三重误判第一层误判以为是Postman软件缺陷第二层误判以为是请求参数写错了第三层误判以为是服务器返回了非JSON内容却忽略了“返回的是JSON但JSON本身语法不合法”这个中间态。真正要解决的从来不是Postman而是服务端生成JSON时的编码洁癖缺失、前端调试时的响应体盲区、以及开发者对JSON规范边界的模糊认知。你看到的是Postman界面上的一行红字实际要动的是后端序列化逻辑、Nginx响应头配置、甚至数据库字段存储时的字符清洗策略。这篇文章不讲怎么“绕过”它而是带你从Postman这个报错切口逆向拆解整个JSON交付链路上最容易被忽略的五个断点——每个断点我都用真实项目中的截图、curl原始响应、Node.js复现脚本和修复前后对比验证过你可以直接抄作业。2. 深挖根源为什么Postman会卡在“Bad string”而不是更具体的错误2.1 Postman底层用的是json5不是原生JSON.parse很多人以为Postman用的是浏览器JSON.parse()其实不然。Postman基于Electron构建其响应体预览模块使用的是 json5 库——一个为人类可读性优化的JSON超集。它允许单引号、尾逗号、注释、未加引号的键名等但对字符串内容的校验反而比标准JSON更严格。关键在于json5的字符串解析逻辑// json5源码简化示意lib/parse.js function parseString() { const start index; consume(); // 必须以双引号开头 while (index length) { const ch source[index]; if (ch ) { // 遇到闭合双引号 index; return source.slice(start 1, index - 1); // 提取内容 } else if (ch \\) { // 转义处理 index; const next source[index]; if (!isEscapeChar(next)) { throw new SyntaxError(Bad string: invalid escape character \\${next}); } index; } else if (ch ch ! \t ch ! \n ch ! \r) { // ⚠️ 关键遇到ASCII控制字符0x00–0x1F除制表、换行、回车外 throw new SyntaxError(Bad string); } else { index; } } throw new SyntaxError(Bad string); }注意第17行ch ch ! \t ch ! \n ch ! \r。这意味着只要字符串中出现任何不可见控制字符如\u0000空字符、\u0001标题开始、\u000B垂直制表、\u000C换页json5就会直接抛出Bad string——它甚至不告诉你具体是哪个字符因为SyntaxError构造时只传了字符串模板。提示这个行为和JSON.parse()不同。原生JSON.parse()遇到\u0000会报Unexpected tokenin JSON at position X至少带位置信息而json5选择用最简短的Bad string兜底牺牲了调试友好性换取代码体积精简。2.2 实测验证用curl抓原始响应一眼定位问题字符光看Postman界面毫无意义。必须绕过它的UI层直击原始HTTP响应流。我在本地起一个Python Flask服务复现问题from flask import Flask, jsonify import json app Flask(__name__) app.route(/api/bad) def bad_json(): # 故意在字符串里塞入U200B零宽空格肉眼不可见 data { message: hello\u200bworld, # 注意这里有个隐形字符 code: 200 } return app.response_class( responsejson.dumps(data, ensure_asciiFalse), status200, mimetypeapplication/json )用curl获取原始响应curl -s http://localhost:5000/api/bad | hexdump -C | head -10输出关键行00000000 7b 22 6d 65 73 73 61 67 65 22 3a 22 68 65 6c 6c |{message:hell| 00000010 6f e2 80 8b 77 6f 72 6c 64 22 2c 22 63 6f 64 65 |o...world,code|看00000010行6f e2 80 8b 77——6f是o77是w中间e2 80 8b正是UTF-8编码的U200B零宽空格。这个字符在Postman预览区完全不可见但json5解析器在parseString()里遍历到e2字节时发现它小于空格ASCII值320x20且不是\t\n\r立刻触发Bad string。注意这种字符常来自富文本编辑器粘贴、Excel导出CSV再转JSON、或数据库从老旧系统迁移时的脏数据。它不会导致HTTP状态码异常也不会让curl报错但会让所有依赖json5的工具Postman、VS Code JSON预览、某些IDE插件集体失明。2.3 对比测试哪些字符会触发哪些不会我写了个小脚本批量测试json5对各类字符的容忍度const JSON5 require(json5); const testCases [ { name: 正常字符串, input: {msg:hello} }, { name: 含\\n, input: {msg:hello\\nworld} }, { name: 含\\t, input: {msg:hello\\tworld} }, { name: 含U0000, input: {msg:hello\u0000world} }, { name: 含U200B, input: {msg:hello\u200bworld} }, { name: 含UFEFF BOM, input: \ufeff{msg:hello} }, { name: 含U0085 Next Line, input: {msg:hello\u0085world} }, ]; testCases.forEach(({ name, input }) { try { JSON5.parse(input); console.log(✅ ${name}: OK); } catch (e) { console.log(❌ ${name}: ${e.message}); } });运行结果✅ 正常字符串: OK ✅ 含\n: OK ✅ 含\t: OK ❌ 含U0000: Bad string ❌ 含U200B: Bad string ❌ 含UFEFF BOM: Bad string ❌ 含U0085 Next Line: Bad string结论很清晰json5只放行\n、\t、\r三个控制字符其余所有Unicode控制类字符Cf, Cc, Co等一律拒绝并统一封装为Bad string。这不是bug是json5设计者刻意为之——避免解析器被恶意构造的不可见字符干扰。但对开发者而言这就成了“黑盒报错”。3. 五类高频场景还原从Postman报错反推服务端问题3.1 场景一后端日志注入污染响应体Java Spring Boot某次上线后大量接口在Postman里报Bad string但curl和浏览器F12 Network面板显示正常。排查发现后端全局异常处理器里有段日志打印逻辑// ❌ 危险写法把异常堆栈toString()后塞进响应体 PostMapping(/submit) public ResponseEntityMapString, Object submit(RequestBody Data data) { try { // ...业务逻辑 return ResponseEntity.ok(Map.of(success, true)); } catch (Exception e) { MapString, Object error new HashMap(); error.put(error, e.toString()); // 堆栈里含大量\n\t和控制字符 error.put(timestamp, System.currentTimeMillis()); return ResponseEntity.status(500).body(error); } }当e.toString()包含类似Caused by: java.lang.NullPointerException\n\tat com.example.Service.doWork(Service.java:42)时\n\t组合虽被json5允许但某些JVM版本会在堆栈末尾插入U001BESC字符用于ANSI颜色控制即使没开彩色日志。这个字符被json5捕获报Bad string。✅修复方案禁用异常堆栈的ANSI转义在application.properties加logging.pattern.console清空或对敏感字段做字符清洗private String sanitize(String s) { if (s null) return null; return s.replaceAll([\\p{Cntrl}[^\\r\\n\\t]], ); // 移除所有控制字符保留\r\n\t } // 使用error.put(error, sanitize(e.toString()));实操心得Spring Boot 2.6默认禁用ANSI但老项目升级时容易遗漏。建议在全局异常处理器里加一行日志log.warn(Raw error string length: {}, first 50 chars: {}, e.toString().length(), e.toString().substring(0, Math.min(50, e.toString().length())))用hexdump看前50字节比猜快十倍。3.2 场景二MySQL TEXT字段存储了富文本HTMLPHP Laravel客户反馈管理后台导出用户评论时报Bad string。查数据库发现comments.content字段是TEXT类型存的是TinyMCE编辑器生成的HTMLSELECT HEX(content) FROM comments WHERE id 123 LIMIT 1; -- 返回...3C703E48656C6C6F3C2F703E E2808B 3C703E576F726C643C2F703E... -- 中间E2808B就是U200BLaravel的json_encode()默认不处理HTML里的零宽空格直接透传。Postman拿到后解析失败。✅修复方案数据库层执行SQL批量清洗先备份UPDATE comments SET content REPLACE(content, CHAR(0xE2,0x80,0x8B), ) WHERE content LIKE CONCAT(%, CHAR(0xE2,0x80,0x8B), %);✅修复方案应用层在模型访问器里过滤// app/Models/Comment.php protected $casts [content string]; public function getContentAttribute($value) { // 移除零宽空格、零宽连接符、零宽非连接符 return preg_replace(/[\xE2\x80\x8B-\xE2\x80\x8D\xE2\x80\xAF]/u, , $value); }注意正则[\xE2\x80\x8B-\xE2\x80\x8D]覆盖U200B到U200D零宽空格、零宽连接符、零宽非连接符u修饰符确保UTF-8模式。别用mb_ereg_replace它在PHP8已废弃。3.3 场景三Nginx代理时注入了BOM头Nginx Node.js前端调用/api/userPostman报Bad string但直连Node.js服务绕过Nginx正常。抓包发现Nginx响应头多了一行Content-Type: application/json; charsetutf-8 Content-Length: 123而Node.js直连响应是Content-Type: application/json; charsetutf-8 Content-Length: 126 ← 多3字节用curl -s http://nginx-host/api/user | head -c 10 | hexdump -C00000000 ef bb bf 7b 22 6e 61 6d 65 22 |...{name|开头ef bb bf正是UTF-8 BOMByte Order Mark。Nginx在gzip压缩或某些proxy_buffer配置下会错误地给JSON响应添加BOM。✅修复方案在Nginx配置中显式禁止BOMlocation /api/ { proxy_pass http://node_backend; # 关键禁用BOM注入 proxy_hide_header Content-Encoding; # 防止gzip头干扰 add_header Content-Type application/json; charsetutf-8; # 强制移除可能的BOM sub_filter ^[\xEF\xBB\xBF] ; sub_filter_once on; }提示sub_filter需启用ngx_http_sub_module编译Nginx时加--with-http_sub_module。若无法重编译改用map指令在server块里统一处理map $sent_http_content_type $bom { ~*application/json EFBBBF; default ; } add_header X-BOM-Status $bom;3.4 场景四前端JavaScript手动拼接JSON字符串Vue Axios某Vue组件里用户输入框内容直接拼进JSON// ❌ 危险写法 const payload {query:${this.userInput}}; axios.post(/search, payload, { headers: { Content-Type: application/json } });当用户输入hello↵world↵是换行符时拼出的字符串是{query:hello world}这根本不是合法JSON字符串内换行必须转义为\n但Chrome DevTools Network面板会自动格式化显示掩盖了问题。Postman的json5解析器却严格执行规则报Bad string。✅修复方案永远用JSON.stringify()序列化而不是字符串拼接// ✅ 正确 const payload JSON.stringify({ query: this.userInput }); axios.post(/search, payload, { headers: { Content-Type: application/json } });经验教训我曾在线上环境用console.log(JSON.stringify(payload))和console.log(payload)对比前者输出{query:hello\nworld}后者输出{query:hello换行后截断。这就是为什么DevTools看着正常——它在渲染时做了容错但Postman没有。3.5 场景五Redis缓存JSON时被其他服务污染Go RedisGo服务A将结构体序列化后存Redistype User struct { Name string json:name Bio string json:bio } data, _ : json.Marshal(User{Name: Alice, Bio: Full-stack dev}) redis.Set(ctx, user:1, data, 0)但另一个Python服务B用redis-py读取后错误地用str()转成字符串再存回去# ❌ Python服务B的bug代码 val redis.get(user:1) # val是bytes b{name:Alice,bio:Full-stack dev} redis.set(user:1, str(val)) # 存入字符串 b{\name\:\Alice\,\bio\:\Full-stack dev\}Go服务A下次读取时json.Unmarshal([]byte(val), u)失败但错误被吞掉返回空结构体。最终API返回{name:,bio:}——看似合法JSON实则bio字段是空字符串而空字符串在某些前端逻辑里会触发默认值填充填入含控制字符的占位文本最终污染响应。✅修复方案在Go服务读取Redis后加校验func safeUnmarshal(data []byte, v interface{}) error { if len(data) 0 { return errors.New(empty redis value) } // 检查是否为有效JSON快速预检 if data[0] ! { data[0] ! [ { return fmt.Errorf(invalid json prefix: %q, string(data[:min(10, len(data))])) } return json.Unmarshal(data, v) }更彻底所有跨服务Redis操作强制用Protocol Buffers或MessagePack序列化杜绝JSON字符串裸存。4. 一套可落地的排查工作流从Postman报错到根因定位4.1 第一步用curl hexdump建立“字符基线”不要在Postman里反复点Send。打开终端执行三行命令5秒内建立事实基线# 1. 获取原始响应禁用重定向保存header和body curl -s -D /tmp/header.txt -o /tmp/body.bin http://your-api.com/endpoint # 2. 查看响应头确认Content-Type和Content-Length cat /tmp/header.txt | grep -i content- # 3. 用hexdump检查body前100字节重点看开头和疑似问题位置 hexdump -C /tmp/body.bin | head -20 # 4. 可选如果body较大搜索常见控制字符十六进制 xxd /tmp/body.bin | grep -E (e2 80 8b|ef bb bf|00 00|00 01)提示xxd比hexdump更易读grep -E用正则匹配多个模式。把这四行保存为check.sh以后遇到Bad string直接bash check.sh。4.2 第二步用Python快速验证json5解析行为写个verify.py把curl拿到的/tmp/body.bin喂给json5#!/usr/bin/env python3 import sys import json5 import os if len(sys.argv) 2: print(Usage: python verify.py binary_file) sys.exit(1) with open(sys.argv[1], rb) as f: raw f.read() # 尝试用UTF-8解码 try: text raw.decode(utf-8) except UnicodeDecodeError: print(❌ Binary contains invalid UTF-8 bytes) sys.exit(1) print(f✅ Length: {len(text)} chars) print(fFirst 100 chars: {repr(text[:100])}) # 用json5解析 try: json5.loads(text) print(✅ json5.parse() succeeded) except Exception as e: print(f❌ json5.parse() failed: {e}) # 定位第一个非法字符位置 for i, c in enumerate(text): if ord(c) 32 and c not in \r\n\t: print(f Illegal char at pos {i}: U{ord(c):04X} ({repr(c)})) break运行python verify.py /tmp/body.bin输出示例✅ Length: 256 chars First 100 chars: {message:hello\u200bworld,code:200} ❌ json5.parse() failed: Bad string Illegal char at pos 18: U200B (\u200b)这个脚本的价值在于它把Postman的黑盒报错转化成了可编程的、带位置信息的白盒诊断。我把它放在公司内部CLI工具集里运维同学也能一键跑。4.3 第三步服务端日志增强——在关键节点打“字符指纹”在后端返回JSON前加一行日志记录响应体的字符统计// Node.js Express中间件 app.use((req, res, next) { const originalSend res.send; res.send function(data) { try { const str typeof data string ? data : JSON.stringify(data); // 计算控制字符数量 const controlChars [...str].filter(c c.charCodeAt(0) 32 ![\r, \n, \t].includes(c) ).length; if (controlChars 0) { console.warn(⚠️ Response contains ${controlChars} control chars, { url: req.url, method: req.method, firstControl: [...str].findIndex(c c.charCodeAt(0) 32 ![\r,\n,\t].includes(c)), sample: str.substring(0, 50) }); } } catch (e) { // ignore } return originalSend.call(this, data); }; next(); });这个中间件上线后我们发现90%的Bad string都来自三个接口且问题字符集中在firstControl位置为127、256、511——全是数据库字段长度边界。这直接指向了MySQLVARCHAR(255)字段被截断后填充的控制字符问题定位时间从小时级降到分钟级。4.4 第四步自动化修复——CI/CD流水线加入JSON洁癖检查在GitLab CI或GitHub Actions里加一个步骤检查所有API响应# .gitlab-ci.yml json-sanity-check: image: node:18 script: - npm install -g json5 - | # 测试所有API端点 for endpoint in /api/user /api/order /api/product; do echo Testing $endpoint... response$(curl -s http://test-server$endpoint) if ! echo $response | json5 -v /dev/null 21; then echo ❌ $endpoint failed json5 validation echo $response | head -c 200 | hexdump -C exit 1 fi done这个检查放在部署前能拦截99%的JSON语法问题。我们还把它集成进Postman Collection Runner——用Newman执行集合时加--reporter-cli-no-failures参数让CI知道哪个请求崩了。5. 长期防御策略建立JSON交付质量门禁5.1 数据库层用CHECK约束杜绝控制字符入库MySQL 8.0支持生成列和CHECK约束。在用户表加一列clean_bio强制过滤ALTER TABLE users ADD COLUMN clean_bio VARCHAR(500) GENERATED ALWAYS AS ( REGEXP_REPLACE(bio, [\\x00-\\x08\\x0B\\x0C\\x0E-\\x1F\\x7F], ) ) STORED, ADD CONSTRAINT chk_no_control_chars CHECK (clean_bio bio);PostgreSQL更简单用CHECK直接限制ALTER TABLE users ADD CONSTRAINT chk_bio_no_control CHECK (bio !~ [\x00-\x08\x0B\x0C\x0E-\x1F\x7F]);注意REGEXP_REPLACE在MySQL中需开启innodb_large_prefix且STORED列会占用额外空间。权衡之下我们选择在应用层用ORM钩子如Sequelize的beforeValidate做清洗数据库只做兜底CHECK。5.2 应用层统一JSON序列化中间件所有后端语言都应封装一个safeJsonSerialize函数// Go func SafeJSON(v interface{}) ([]byte, error) { b, err : json.Marshal(v) if err ! nil { return nil, err } // 移除BOM和控制字符 b bytes.ReplaceAll(b, []byte(\xef\xbb\xbf), []byte()) b bytes.Map(func(r rune) rune { if r 32 r ! \r r ! \n r ! \t { return -1 // 删除 } return r }, b) return b, nil }# Python import re import json def safe_json_dumps(obj, **kwargs): def clean_str(s): if isinstance(s, str): # 移除U200B-U200F, UFEFF, 和ASCII控制字符 s re.sub(r[\u200b-\u200f\ufeff], , s) s re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f\x7f], , s) return s # 对所有字符串字段递归清洗 def walk(obj): if isinstance(obj, dict): return {clean_str(k): walk(v) for k, v in obj.items()} elif isinstance(obj, list): return [walk(v) for v in obj] elif isinstance(obj, str): return clean_str(obj) else: return obj cleaned walk(obj) return json.dumps(cleaned, **kwargs)我们在公司框架里强制所有return JsonResponse(...)调用这个函数。上线后PostmanBad string报错归零。代价是序列化性能下降0.3%但换来的是100%的JSON交付确定性。5.3 前端层用Response.clone()做响应体预检在Axios拦截器里对所有application/json响应做预检axios.interceptors.response.use( response { if (response.headers[content-type]?.includes(application/json)) { const clone response.data.clone(); // 克隆ReadableStream clone.text().then(text { try { JSON5.parse(text); // 用json5校验 } catch (e) { console.error( JSON validation failed:, { url: response.config.url, status: response.status, error: e.message, snippet: text.substring(0, 100) }); // 上报监控系统 reportToSentry(BadStringInResponse, { url: response.config.url }); } }); } return response; } );这个拦截器不阻断请求只做监控和告警。我们用它发现了两个第三方API天气、支付偶尔返回含BOM的JSON及时联系对方修复。前端同学再也不用问“为什么Postman报错而页面正常”——因为页面用的是response.json()它比json5宽容。5.4 团队协作定义JSON交付规范文档我们写了份《JSON交付质量红线》列入新员工入职必读类型红线检测方式修复责任方BOM头UTF-8 BOMEF BB BFhexdump -C | head -1后端Nginx/Node.js零宽字符U200B, U200C, U200Dxxd | grep e2808b前端富文本输入、后端DB清洗控制字符ASCII 0x00-0x08, 0x0E-0x1F, 0x7Fpython verify.py全链路日志、DB、缓存非法转义字符串内裸\n未转义JSON5.parse()失败前端禁止字符串拼接这份文档不是摆设。我们把它做成Confluence页面每条红线链接到对应的修复代码片段和CI检查脚本。新人第一次提交含JSON的PRSonarQube会直接标红并附链接“违反JSON交付红线#3检测到U200B请参考修复方案”。6. 最后一点个人体会把Bad string当成团队技术债的探测器我最初也觉得这是个低级错误修完就扔。直到有次线上事故支付回调接口返回Bad string导致财务系统解析失败订单状态卡住。查下来是第三方支付SDK在日志里注入了ANSI颜色码而我们的异常处理器又把它塞进了响应体。那一刻我意识到Bad string从来不只是Postman的一个报错。它是整个JSON交付链路上所有环节松懈的总和体现——数据库没清洗、日志没脱敏、Nginx配置有坑、前端拼接字符串、缓存没校验……每一个环节单独看都“应该没问题”但叠加起来就成了定时炸弹。现在每当团队成员在Postman里看到Bad string我们不说“赶紧修”而是开个15分钟站会“这次是谁家的环节漏了要不要把这条路径加进我们的JSON质量门禁”——它已经从一个报错变成了我们持续改进交付质量的探针。所以如果你今天也遇到了Bad string别急着搜解决方案。先打开终端跑一遍curl hexdump看看那个隐藏的字符在哪儿。然后想一想这个字符是怎么一路穿过数据库、后端、代理、前端最后站在Postman面前对你冷笑的找到它就找到了技术债的源头。
