Postman中Raw视图显示的\n是后端返回的真实转义字符，非渲染假象；Pretty/Preview视图会美化换行，调试应以Raw为准，并用Tests脚本模拟JSON.parse验证实际解析结果。
Postman里看到的
是真实换行符，不是显示问题
Postman 的 Pretty 视图会把 JSON 中的
渲染成换行，但这是它在“帮你美化”，不代表原始响应体里没有这个字符。你真正要关心的是：Android 或前端 JS 解析后拿到的字符串值是否含不可见换行——这直接影响字段比对、数据库写入或 UI 渲染。Raw 视图才是真相，里面能看到原样 "username": "admin2
"，而不是换行后的排版效果。
- 切到 Raw 视图看实际字节流，避免被 Pretty 的渲染误导
- 如果 Raw 里出现
- Preview 和 Visualize 视图会进一步“消化”转义，更不可信，调试阶段一律禁用
用 JSON.parse() 模拟客户端解析行为
别只盯着 Postman 看，得验证 JS 实际怎么处理这个字符串。在 Tests 标签页里写一行脚本：console.log(JSON.parse(pm.response.text()).username)，然后打开 Postman Console（View → Show Postman Console），看输出末尾有没有空行或异常截断。
- 如果输出是
"admin2 "（末尾带空格）或直接报错SyntaxError: Unexpected token，说明后端返回了非法 JSON（比如没转义的裸 - 如果输出是
"admin2 "（字符串字面量含 - 注意：Postman 的 Tests 运行环境是沙箱化的 JS，和浏览器/Android 的
JSONObject行为基本一致，可放心模拟
断言时必须匹配转义后的字符串形态
想用 Response body: Is equal to a string 断言一个含
的字段？直接写 {"message":"ok
"} 会失败。因为 Postman 断言脚本运行在 JS 环境里，
被解释为换行符，而响应体里是字面量
（即两个反斜杠）。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 正确写法是双写反斜杠：
{"username":"admin2\n"}—— 第一个转义第二个，最终匹配到响应中的 - 若字段含中文+换行，比如
"msg": "成功 "，断言字符串应写为：{"msg":"成功\n"} - 更稳妥的做法是改用
JSON value check断言，它自动解析响应为对象，再取json.msg值做比较，避开字符串转义陷阱
后端不清理输入，Postman 再怎么查也救不了
Postman 只是观察者，不是修复者。你在 Raw 里看到
，99% 源头是数据库字段存了回车、日志拼接污染、或用户粘贴时带了不可见字符。Spring Boot 用 @NotBlank 挡不住换行符，PHP trim() 默认也不清
，Node.js req.body.xxx.replace(/s+$/g, '') 才管用。
最容易被忽略的一点：PostgreSQL 的 text 字段默认允许存储任意空白字符，且 pg_dump 导出时不会警告；MySQL 的 VARCHAR 在严格模式下才拒绝末尾空格。所以光看 Postman 响应没用，得顺藤摸瓜查数据库原始值。
