上周调试一个前后端联调问题，死活解析不了接口返回的 JSON。控制台报错“unexpected token”，我反复核对字段名、引号、逗号，样样合规。最后发现——后端哥们在 JSON 字符串末尾塞了个不可见的 Unicode 空格（U+200B），肉眼根本看不出来！JSON.parse() 直接炸了。从此养成习惯：所有外部字符串进 parse 前先 trim() + 正则清杂字符。这年头，数据干净比代码干净还难。
——sudo make me a sandwich

太真实了！去年对接某欧洲供应商API也踩过类似坑，他们返回的JSON里混了U+FEFF（BOM头），parse直接崩。现在我所有fetch response都先过一遍.text().then(s => s.trim().replace(/[\u200B-\u200D\uFEFF]/g, ''))再JSON.parse。btw，建议后端兄弟们用JSON schema校验输出，比前端擦屁股高效多了。——Talk is cheap, show me the code

U+200B 这种隐形刺客真的防不胜防！去年做外贸订单导入也栽过，客户Excel里复制的数据带了零宽空格，JSON 解析直接崩。现在我连 trim() 都不够信任，得上 /\u200B/g 这种正则硬清。btw，后端能不能在返回前自己 sanitize 一下？前端擦屁股擦到手软 literally… ——sudo make me a sandwich

哈哈这锅我也背过！！之前拍片导数据，甲方给的CSV里藏着各种隐形字符，导入数据库直接乱码，我以为是编码问题折腾了仨小时…后来学乖了，所有外部数据先过一遍清洗流程，宁可多写十行代码也不信肉眼 (╯‵□′)╯︵┻━┻

——人生苦短，及时灌水

U+200B 这种零宽空格简直是数据清洗的幽灵字符！我在肯尼亚做援建项目时也踩过类似坑——当地合作方系统导出的 CSV 里混了 U+FEFF，Python pandas 直接把第一列名读成"id"（带BOM头）。现在所有外部输入进解析器前，我必先跑一遍 normalize(‘NFKC’) + trim()。建议兄弟把正则规则贴出来，大家共建个“脏数据黑名单”？——格物致知，正心诚意