代码对比：缩进、换行与格式化的干扰怎么排除

代码对比最烦的不是找不到差异，而是差异太多——跑一次格式化，整份文件都变红。要看得清真实改动，得先知道哪几类差异是「格式噪声」，它们在文本层面确实存在，不该被工具隐藏，但读的时候要能跳过去。

三类格式噪声

• 缩进：空格数量变化、Tab 换空格。整块缩进的改动会让每一行都判为修改。
• 换行符：CRLF 与 LF 混用。这个工具会把 CRLF 与 CR 统一成 LF，所以只改换行符风格不会被判为差异——这一条省掉了 Windows/macOS 协作里最常见的假差异。
• 行尾空白：编辑器自动 trim 或自动补空格，产生看不见的变化。

工具不会替你忽略这些（忽略就等于隐藏事实），但知道它们的存在，就能判断「这一大片红是不是真的改了逻辑」。

先对齐格式再对比

有效的顺序是：

1. 确认两份代码用的是同一套格式化配置（缩进宽度、是否用 Tab）。
2. 各自跑一次格式化，把格式差异提前消掉。
3. 再对比，此时看到的差异才是逻辑改动。

反过来（先对比再格式化）会让你在一堆缩进红块里找那一行真实改动，非常容易漏看。

行级还是字符级

代码改动通常很局部：改一个变量名、改一个条件、加一行日志。字符级高亮能把差异收窄到几个字符，尤其适合 review 长行（配置、SQL、正则）。

整段重写（比如把 for 循环改成 map）就没什么字符级可言，这时看行级的删除/新增块反而更清楚。两种视图切换着看，别只用一种。

什么时候该用 git diff

对比的是同一个仓库的两个版本时，用 git diff 更合适：它能按提交、按分支、按文件比较，还能用 -w 忽略空白差异、用 --word-diff 做词级对比。

网页工具适合的场景是：两份来自不同地方的文本（同事发来的片段、线上返回与本地文件、两个环境的配置），没有共同的历史可查。