1. 为什么你的Prettier总在抱怨Delete ␍？
最近在Windows和Mac混合作业的环境里，每次保存文件都会看到那个烦人的"Delete ␍"警告？这其实是换行符在作祟。Windows系统默认使用CRLF（\r\n）作为换行符，而Unix/Linux/macOS系统则使用LF（\n）。当你在Windows上开发，而团队其他成员用Mac时，Prettier就会因为换行符不一致而报错。
我刚开始用Prettier时也经常被这个问题困扰，直到有次提交代码后，Git显示整个文件都被修改了——其实只是换行符被自动转换了。这种问题在跨平台协作中特别常见，特别是当项目没有统一换行符规范时。
2. 换行符冲突的底层原理
2.1 操作系统间的历史差异
换行符的不同要追溯到打字机时代。CR（Carriage Return，回车）让打印头回到行首，LF（Line Feed，换行）让纸向上移动一行。Windows继承了DOS的传统，同时需要CR和LF，而Unix系系统认为LF就够了。
在现代开发中，这种差异会导致：
- Git diff显示大量无关修改
- Prettier等工具报错
- 跨平台协作时代码风格混乱
2.2 Prettier如何处理换行符
Prettier默认会根据当前操作系统自动选择换行符，但这在混合环境中反而会造成问题。更糟的是，不同编辑器可能有不同的换行符处理逻辑。比如VSCode默认会跟随系统，而WebStorm则提供了更多控制选项。
3. 一劳永逸的解决方案
3.1 项目级配置：.prettierrc
在项目根目录创建或修改.prettierrc文件：
{ "endOfLine": "lf" }这个配置会强制Prettier使用LF换行符，无论什么操作系统。我在所有项目中都这样设置，彻底避免了团队协作时的换行符问题。
3.2 编辑器配置：.editorconfig
.editorconfig是跨编辑器统一代码风格的利器：
root = true [*] end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true这个配置不仅解决了换行符问题，还确保了文件编码、尾随空格等其他风格一致。主流编辑器都支持EditorConfig插件，安装后会自动应用这些规则。
3.3 VSCode专属设置
如果你用VSCode，可以在设置中搜索"files.eol"，然后设置为"\n"。或者在settings.json中添加：
{ "files.eol": "\n" }更便捷的方法是点击编辑器状态栏的换行符指示器（右下角的CRLF或LF），直接切换当前文件的换行符格式。
4. 修复现有项目的换行符问题
4.1 一次性批量修复
对于已有项目，可以运行：
npx prettier --write .这个命令会按照.prettierrc配置重新格式化所有文件，包括统一换行符。第一次运行时可能会修改大量文件，建议单独提交这次变更，方便后续review。
4.2 Git的换行符处理
在.gitattributes文件中添加：
* text=auto eol=lf这能确保Git在检出文件时自动将换行符转换为LF，同时在提交时转换为LF。我在项目中都会加上这个配置，特别是当团队中有Windows开发者时。
5. 高级场景与疑难解答
5.1 混合换行符的项目
有时项目中既有LF又有CRLF文件，可以用这个命令检查：
grep -l $'\r' * | grep -v node_modules找到问题文件后，可以用dos2unix工具批量转换：
find . -type f -name "*.js" -exec dos2unix {} \;5.2 CI/CD中的换行符检查
在GitHub Actions中添加这一步，确保不会引入CRLF：
- name: Check line endings run: | if grep -l $'\r' $(find . -type f -name "*.js"); then echo "CRLF line endings detected!" exit 1 fi6. 预防胜于治疗：建立团队规范
最好的解决方案是在项目初期就统一换行符规范。我现在的做法是：
- 项目初始化时立即添加.prettierrc和.editorconfig
- 在README中明确换行符规范
- 在项目模板中预置这些配置
- 在Code Review中检查换行符变更
对于新加入的开发者，我会建议他们在第一次克隆项目后就运行prettier --write，确保本地环境与项目规范一致。
