VSCode中快速定位Unicode控制字符需启用正则模式（点.*按钮），搜索[\u202a-\u202e\u2066-\u2069]；批量删除推荐在搜索替换框中用该正则替换为空，或使用sed命令、Node.js脚本清洗。
VSCode 里清理文本中的特殊编码（比如不可见控制字符、BOM、错误的 UTF-8 序列）不能靠“猜”，得按字符类型分层处理：先定位，再删，最后验证是否真干净。
怎么快速定位 \u202a-\u202e 和 \u2066-\u2069 这类 Unicode 控制字符
这类字符（LRE、RLE、PDI、FSI 等）本身不可见，但会破坏光标定位、Git diff 甚至正则匹配。VSCode 提示“包含不可见的控制字符”只报存在，不标位置。
- 必须打开搜索框右上角的
.*按钮（启用正则模式） - 搜索内容填：
[\u202a-\u202e\u2066-\u2069]—— 注意别漏掉\u2066-\u2069，新版文档里更常见 - 大文件可能只显示前 100 个匹配，需手动滚动或分段搜索；若完全搜不到，检查是否误关了正则模式
如何安全批量删除控制字符，又不误伤空格和缩进
直接全选 + 替换为空极危险：可能吃掉行首缩进、JSON key 中的空格，甚至把 "key": "value" 变成 "key":"value"。
- 在 VSCode 查找替换中，填入
[\u202a-\u202e\u2066-\u2069]，替换为留空，点Replace All—— 这是最准、最快、保留格式的方式 - 命令行批量处理（适合脚本）：
sed -i 's/[\xe2\x80\xaa-\xe2\x80\xae\xe2\x81\xa6-\xe2\x81\xa9]//g' file.txt，注意sed必须支持 UTF-8，macOS 默认sed不行，得用gsed - Node.js 清洗（适合 CI）：
fs.readFileSync('file.txt', 'utf8').replace(/[\u202a-\u202e\u2066-\u2069]/g, '')，再写回
为什么删完 Git 还提示“内容变更”，甚至中文看起来没变
控制字符被删后，字符串长度变了，Git 当然检测到差异。但更隐蔽的是：某些编辑器（如旧版 Notepad++ 或微信粘贴）会在行首悄悄插一个 \u202a（LTR embedding），删掉它，视觉上中文位置“没动”，实际少了一个字符。
- 这种变化在 Markdown 表格、JSON key、YAML 键名中特别致命——可能让解析失败
- 删完务必执行：
git diff --ignore-space-at-eol，如果仍有差异，说明不是空格问题，而是控制字符残留或误删 - 特别注意
UTF-8 with BOM：VSCode 右下角显示“UTF-8”时，可能是带 BOM 的。BOM（\ufeff）不在上述正则范围内，得单独搜\ufeff或用^[\uFEFF]定位
清理后还要防反弹：怎么避免下次再混进来
控制字符大多来自复制粘贴（尤其是网页、微信、钉钉）、旧系统导出数据或跨平台协作。光清一次没用，得卡住入口。
- 禁用 VSCode 自动猜测编码：
"files.autoGuessEncoding": false，防止它把 GBK 文件错解成 UTF-8，再“保存为 UTF-8”时硬塞进乱码字节 - 对高风险文件类型（如
.md,.txt,.csv）强制指定编码："files.associations": { "*.md": "utf8", "*.txt": "utf8" } - 终端输出中文不乱码，不是编辑器问题：Windows 下必须设
"terminal.integrated.env.windows": {"PYTHONIOENCODING": "utf8"}，否则 Python 输出的 UTF-8 字节会被 cmd 当 GBK 解码
真正难的不是删，是识别哪些字符该删、哪些看似“空”实则关键（比如 BOM、零宽空格 \u200b）、以及删完后是否影响下游工具链。每次清理完，建议用 xxd file.txt | head 看二进制开头，确认没有 ef bb bf（BOM）或奇怪的 e2 80 xx 字节残留。
