代码里最阴险的bug，往往不是逻辑写错了，是肉眼看不见的东西在捣乱。
简单说
前阵子写脚本，从网页文档copy一段配置字符串paste进编辑器，一编译就报错。报错行我瞪了十几分钟，字符一个个对过去，看着没问题。后来整行删掉手打一遍，立刻过了。问题不在逻辑，是那串里混了个零宽空格(U+200B)。
这种字符最烦。编辑器里不显形，git diff也不标红，肉眼根本抓不到。其实你以为是算法写岔了，花几小时翻逻辑，罪魁却是个看不见的空格。零宽空格、全角空格、文件头BOM，都是常客。
我现在的处理：编辑器开显示不可见字符（VS Code搜renderControlCharacters），或者 rg -P ‘[\x{200B}\x{A0}]’ 扫一遍项目，几秒定位。从网页copy代码，先丢进记事本过一道再进项目。
Друг，这坑踩过三回，每回白耗一下午。编译器报的错，先怀疑字符，再怀疑自己。
记事本过一道这招我也在用。从网页扒来的东西表面干干净净，暗地里尽是这种看不见的空格，坑死人
这种看不见的东西最磨人。我印象里最离谱的一次，是个脚本死活跑不起来…，报错说找不到文件。我把文件名复制出来贴进终端，ls 明明能看到，它偏喊 no such file。磨到后半夜才发现文件名末尾粘了个换行符，终端和肉眼都看不出，ls 显示也正常，删掉重打，秒好。
你说的零宽空格、全角空格、BOM 这三样我都碰过。不过有一类你大概还没格外留神：行/段分隔符 U+2028、U+2029。这俩在 JSON 和老版 JS 引擎里算合法换行，字符串里混进去，parse 或者某些正则直接崩，报错还完全不往字符上指，特别能把人往逻辑里带。
那会儿再往外补一句。以前不是这样的——早些年大家用 GBK，乱码是明晃晃糊你脸上，现在 UTF-8 太平了，问题反倒藏得更深。而且这类字符如今已经不只是手滑：前两年安全圈炒的 trojan source，就是靠 U+202A 到 U+202E 那几个书写方向控制符，把显示顺序和机器读取顺序拆开，肉眼看着是段注释，跑的却是另一段逻辑。怎么说呢还有 homoglyph，西里尔 а 和拉丁 a 一个样，变量名换掉，编译能过，查起来能把人整疯。所以"先怀疑字符"现在越来越该是下意识动作了。
工具上你那招 rg 很好使。我习惯再加两条：git 把 whitespace 高亮打开，diff 直接标红；拿 hexdump -C 或 cat -A 兜底扫一眼，控制字符全现原形。从网页过一道记事本也对，不过我懒，直接开 renderControlCharacters。
说到底这类 bug 费时间不在难，是它颠覆了眼见为实——我们默认看见的就是全部，可文本底下还压着一层平时不关心的编码层。多一层怀疑，少一下午冤枉路。
顺便，你结尾那个 Друг 用的就是西里尔字母，跟我说的 homoglyph 正好凑一对，哈哈。
结尾那个Друг用得莫名有点浪漫啊，赛博朋克版的老铁。
我去说真的这种bug确实阴。我之前也中过招，不过不是配置字符串，是从PDF里扒了一段东西想拿去处理，死活跑不对，最后发现有几个全角空格混在里面。当时也是一行行对，怀疑自己眼神出了什么问题。我去
呵呵你那个rg扫项目的法子我存了，比我自己笨办法强——我之前是靠肉眼加运气，效率低得离谱。不过renderControlCharacters这个我也早开了，开了之后才发现日常复制粘贴里藏的零宽字符多到离谱，有些网页它自己就给你塞。
最气的是你说的那句，编译器报错先怀疑字符再怀疑自己，太真实了。踩三回说明这坑确实防不胜防，毕竟它连显示都不显示，属于是C’est la vie了。
白耗一下午最磨人了，明明不是自己笨，是看不见的东西在使坏，越想越憋屈。理解的
我早些年也栽过类似的东西，比这还隐蔽——从一份老文档里复制的引号，看着是直的，其实是 Unicode 的弯引号（“” ‘’ 那种）。编译一直报字符串没闭合，我对着那行瞪半天，怎么看都是一对正常的引号。最后还是靠把文件按字节扫了一遍才揪出来。
你说的先丢进记事本过一道，真的实在。我后来也养成习惯了，凡是网页、微信里来的代码片段，一律先 paste 到纯文本里洗一道，宁肯多这一步，也不想再搭进去一个下午。是呢
理解的
rg 那个命令我得存一下，比我之前用的 grep 顺手多了。
盯着那行字瞪了十几分钟，这种空落落的挫败感真不好受。明明什么都没看见，错却实打实地杵在那儿，像夜里走路踢到了看不见的门槛。
你那句“先怀疑字符，再怀疑自己”，我倒觉得挺有意思。人总愿意相信眼睛，可屏幕上这些零宽空格，偏生是眼睛够不着的。编辑器不显形，git不标红，它就安安静静躲在字缝里，比谁都沉得住气。
我现在也是，从网页扒来的东西，一律先丢进最素的文本框里滤一道。就当是把浑水沉淀沉淀，等那些看不见的泥沙沉到底，再放心舀上面清的用。
我也被这玩意坑过，瞪屏幕瞪到眼瞎。emmm你那招丢记事本过一道虽土但真灵，rg那条我存了。说真的，以后copy网页都得当贼防着。
我去年也叫这东西坑过，BOM头害脚本死活跑不起来，折腾半天才揪出文件头那仨字节。记事本过一道，实在的法子。
顺着一个细节较个真：你正文把"全角空格"列为常客，但下面正则写的是 \x{A0}，这两样不是同一个东西。\x{A0} 是 U+00A0（non-breaking space，不间断空格），归在 Latin-1；全角空格是 U+3000，属 CJK。外观都像"一个空白占位"，编码来源却差很远。
更该分清的是，全角空格在编辑器里其实看得见，它稳占一个汉字宽度，只是容易被误当普通缩进。真正"肉眼抓不到"的是零宽一类：U+200B、U+200C/D、U+FEFF，它们压根不占位。所以"肉眼根本抓不到"用在零宽字符上成立，套全角空格就不成立了。
我自己的处理跟你接近，但会多扫一类：U+2028 / U+2029 行分隔符。这俩在老版本 JS 引擎里会被当换行，藏在字符串里能把脚本直接弄崩，同样不显形，那条正则没覆盖到。
另外 BOM 挺看工具。UTF-8 带 BOM 在 VS Code 里基本无害，可一旦出现在 shell 脚本 shebang 行前（#! 之前多三字节），bash 就认不出解释器，那种报错最让人懵。"先丢记事本过一道"对去 BOM 不一定灵，记事本存 UTF
顺带提一句，你rg里那个\x{A0}是普通不换行空格，不是零宽字符，零宽其实是\x{200B}。再把全角空格\x{3000}加进去一起扫更省事。
补充一点：VS Code 的 renderControlCharacters 不显示零宽空格，它是格式字符不是控制字符。抓 U+200B 还是得靠 rg 扫或装个插件。
这坑我去年也栽过一回，比你的还难查——写了个 shell 脚本，本地跑得好好的，扔到服务器上直接报 ‘/bin/bash^M: bad interpreter’。原因是之前在 Windows 上改过，不小心混进了 CRLF，每行行尾多了个 CR。cat -A 一打，结尾全是 ^M$，对着源码瞪了半天愣是没看出来。
顺着你说的"常客"名单补几个：U+202E 从右到左覆盖符不单是显示问题，还能拿来做文件名欺骗，安全圈前几年讨论过一阵；还有软连字符 U+00AD、零宽连接符 U+200D，混进字符串同样不显形。另外提个小修正——VS Code 那个 renderControlCharacters 主要管 0x00–0x1F 这段控制字符，零宽空格显不显跟版本和主题都有关，开了不一定看得见。真要排查还是你那行 rg 靠谱，我一般再叠个 xxd 定位到具体字节才踏实。