统一换行符怎么用：Git diff 里的 ^M 是怎么来的

从 Windows 或旧 Mac 拿到的文本，粘进 Linux 脚本、Git 或在线编辑器时常冒出 ^M 和多余空行。转换后所有换行都是 LF，肉眼看不出来，但提交以后 diff 就干净了。

什么时候需要统一换行符

同一份代码在 Windows 上编辑、在 Linux 上运行，Git diff 里每个文件都显示成「整份改动」，其实只是行尾从 CRLF 变成了 LF。团队里有人用 Windows、有人用 macOS 时，这种噪音天天出现，review 根本看不清真实改动。

另一个场景是脚本报错：从网页或聊天窗口复制的 shell 脚本，行尾带 CR，执行时报 bad interpreter，或者命令后面多出一个不可见字符。把换行统一成 LF，问题通常立刻消失。配置文件、CSV、字幕文件也有同样的坑。

CRLF（Windows，先回车再换行）和单独的 CR（旧 Mac）都会被替换成 LF，其他字符一个都不动。替换后文本框里看起来和原来完全一样，因为三种换行在文本框里都显示为换行，肉眼分辨不出来。

要确认真改了，把结果粘到能显示不可见字符的编辑器里看行尾，或者提交后看 Git diff 里还有没有 ^M。注意它只换行尾，空行、行尾空格、缩进都原样保留，需要清理得配合其他工具。

它不改变文件编码（UTF-8、GBK、UTF-16 都不动），也不处理 BOM。如果文件本身编码不对，换行统一了照样会乱码，那是另一个问题，需要编码转换工具来解决。

对整个仓库来说，逐份粘贴不现实。正确做法是在仓库里配置 .gitattributes 的 text=auto，或者用 dos2unix、编辑器批量转换。网页工具适合单个文件或一段文本，不适合当作长期方案。

结果看起来和原文一模一样，真的改了吗？

改过了。文本框里两种换行都显示成换行，肉眼看不出来。要确认的话，把结果粘到能显示不可见字符的编辑器，或者在 Git 里看 diff 是否还有 ^M。

会顺便删掉多余空行或行尾空格吗？

不会。只替换换行符本身，空行、行尾空格和缩进都原样保留。需要清理，配合「去掉行首行尾空格」使用，或先用删除空行的工具处理。

CRLF 和 LF 到底有什么区别？

CRLF 是两个字符（回车加换行），Windows 记事本常用；LF 是一个字符，Linux 和 macOS 常用。两者在编辑器里看起来一样，但按字节比较就不同，Git 和脚本会因此报错。