Notepad++ 默认不支持 \u200B 等 Unicode 转义，需改用 \x{200B}（UTF-8 编码+勾选正则表达式）或直接粘贴零宽字符；批量清理可用 [\x{200B}-\x{200D}\x{FEFF}\x{2028}\x{2029}\x{00A0}] 正则替换为空。
Notepad++ 里搜不到 \u200B？因为默认正则不认 Unicode 转义
直接在「查找」框输 \u200B 或 u200B，勾选「正则表达式」——完全没反应。这不是你操作错，是 Notepad++ 的 PCRE 引擎默认不解析 \uXXXX 这类 Unicode 转义序列。它只认字面字符或十六进制写法 \x{200B}（需启用“UTF-8 模式”且版本 ≥7.9）。
更实际的办法是：复制一个真正的零宽空格字符（可从出问题的文本里 Ctrl+C 一段可疑内容，粘贴到记事本再复制一次，有时能保留），然后在 Notepad++ 查找框里直接粘贴这个看不见的字符。勾选「匹配全部字符」和「正则表达式」，点「全部高亮显示」确认是否真有命中。
- 如果粘贴后查找框变空或报错，说明剪贴板没带过去——换用十六进制方式：
\x{200B}，但必须先确保文件编码是 UTF-8（右下角状态栏显示「UTF-8」），并勾选「匹配全部字符」 - 别用「扩展模式」，它把
\x{...}当普通文本处理 - 搜索前先打开「视图 → 显示符号 → 显示所有字符」，看有没有异常小点或方块，这是最直观的线索
批量删 \u200B、\uFEFF、\u200C 等常见零宽控制符
单个删效率低，且容易漏掉其他干扰符（比如 \u200C 零宽非连接符、\uFEFF BOM、\u00A0 不间断空格）。推荐一次性清干净：
打开「替换」对话框（Ctrl+H），填入：
查找目标：[\x{200B}-\x{200D}\x{FEFF}\x{2028}\x{2029}\x{00A0}]
替换为：（留空）
- 必须勾选「正则表达式」和「匹配全部字符」
- 编码必须是 UTF-8，否则
\x{...}不生效 - 这个范围覆盖了最常导致 JSON 解析失败、正则匹配崩、HTML 校验报错的几类字符
- 不会误伤普通空格、制表符或换行符——它们不在这个 Unicode 区间内
删完还报错？检查是否残留 \u200B 在字符串中间或注释里
很多人删完以为搞定了，结果代码一运行还是莫名中断。常见原因是：\u200B 被插在变量名中间、JSON key 里、或 HTML 属性值中——肉眼根本看不出，但 JS 引擎或 XML 解析器会把它当真实字符处理。
- 用浏览器开发者工具 Console 执行
JSON.stringify(yourString)，如果返回里出现"u200b"，就坐实了 - 在 Notepad++ 中对疑似段落执行「全部高亮显示」+ 上述正则，看是否还有未命中的高亮（可能因编码切换失败导致）
- 特别注意复制粘贴来的第三方代码、Markdown 表格生成器输出、或从网页直接扒的 HTML 片段——这些是重灾区
- 如果文件含 emoji 或中文混合内容，别用 ANSI 编码打开再操作，否则
\x{200B}会被截断成乱码，替换失效
长期避免踩坑：别依赖「显示所有字符」来判断是否干净
「视图 → 显示符号 → 显示所有字符」只能暴露部分不可见字符（如空格显示为 ·，制表符为 →），但 \u200B 在多数字体下仍不显示任何图形，只占位。这意味着：界面看起来干干净净，实际埋着雷。
- 真正可靠的验证方式只有两种：用
JSON.stringify()看是否显形，或用命令行xxd yourfile.txt | grep 200b（Linux/macOS）查十六进制 - 日常编辑建议开启 Notepad++ 的「自动清除尾部空白」（设置 → 首选项 → 常规 → 保存时自动清除尾部空白），虽不解决零宽问题，但减少一类干扰源
- 涉及配置文件、JSON、XML、SQL 导入等敏感场景，替换完务必用外部工具二次校验——Notepad++ 的 GUI 操作再稳，也绕不开 Unicode 渲染盲区
