翻一套工业数据 WebApi 的源码时，我先被一个拼写卡住了。
项目里有个业务层目录，叫 Bussiness。多了一个 s。
（等价改写，名字换掉了）它长这样：
namespace Contoso.WebApi.Bussiness // 多了一个 s
{
public class BussinessController { }
}
这一个错，不是只在目录名里。全仓搜一下，这个拼错的 Bussiness 命中 3985 处。一个手滑的单词，被复制了近四千次。
它是怎么蔓延的
命名这东西，第一次写错是偶然，后面全是被"照着抄"。新模块要引用业务层，IDE 自动补全给的就是那个错的名字，复制粘贴的人根本不会多看一眼。错的命名一旦进了公共接口，就成了契约——下游所有调用方都得跟着拼错，改一个就编译不过一片。
我没法确认是谁第一次多打了那个 s，也没法确认当时为什么没拦住。但更可能的情况是：早期没有命名规范检查，第一个目录名定下来，后面就都顺着它走了。
代价是具体的
近四千处，意味着这个错已经不是"改一个文件"能解决的。它是地基里的错字，上面盖了多少层，就牵连多少层。
更隐蔽的是信任。新人看到 Bussiness，第一反应是"原来你们就这么叫"，于是他也这么写、这么读。错的命名会被当成正确的术语传播，等有人想纠正，阻力已经不是技术，是"大家都这么用"。
改起来比想象中费劲
我后来给这套代码配了命名分析器，把 Bussiness 这类指纹列进禁止列表，新代码一写就标红。存量那近四千处，靠一次性的重命名加编译验证慢慢收。最关键的一步其实不是改，是让这个错不再被复制。
一个单词的拼写，决定不了程序跑不跑得起来。但它会决定，后来读这段代码的人，是更容易相信这里，还是先疑神疑鬼。