右下角显示CRLF或LF表示当前文件实际使用的换行符类型：CRLF（\r\n，Windows）或LF（\n，Unix/Linux/macOS），是状态指示器而非错误；点击可临时切换，但仅对当前文件本次编辑生效，保存后才写入磁盘，重启或重新打开不会保留，除非配置files.eol、.gitattributes和Git core.autocrlf协同统一。
右下角显示CRLF或LF代表什么
它不是错误提示，而是VSCode在告诉你：当前文件里所有换行符的类型是 CRLF（\r\n，Windows风格）或 LF（\n，Unix/Linux/macOS风格）。这个标识会实时反映文件内容的实际字节序列，也决定了你按回车键后插入的是哪一种换行符。
常见误解是把它当成“格式警告”，其实它只是状态指示器——但一旦你编辑后保存，VSCode 就会按这个类型重写整份文件的换行符。所以如果你看到 CRLF 却想用 LF，不点一下切换，保存时就会把 \r\n 写死进文件。
为什么点了切换，关掉再打开又变回去了
因为点击右下角只修改当前文件的**内存中表示**，不改配置、不改 Git、也不影响其他文件。它本质是一次性操作，适合单文件救急。
- 你点完选
LF→ 编辑器立刻按\n渲染所有换行 → 但没Ctrl+S，关掉就丢弃 - 你点了并
Ctrl+S→ 文件磁盘内容变成LF→ 下次打开仍显示LF（只要没被 Git 或其他工具覆盖） - 但如果项目里有
.gitattributes设了eol=crlf，或者你用file://直接打开单个文件（而非通过文件夹打开工作区），VSCode 可能忽略这次选择，下次打开仍按规则还原
怎么让新文件一创建就是LF（Windows用户尤其注意）
Windows 上 VSCode 默认新建文件用 CRLF，这是平台行为，不是 bug。想统一为 LF，必须手动设 files.eol：
- 打开
Settings (JSON)（Ctrl+,→ 搜files.eol→ 点Edit in settings.json） - 添加或修改这一行：
"files.eol": "\n"（注意是字符串"\n"，不是文字 “LF”） - 保存后执行
Ctrl+Shift+P→ 输入Developer: Reload Window重启窗口，否则设置不生效 - 这个设置只对“未指定换行符的新建文件”起作用，比如新建一个空
.js，不会影响已存在的文件
别漏掉 files.preferredLineEnding：设成 "lf"（字符串，不是 "\n"），它会优先读取 .gitattributes，更适合团队协作场景。
为什么改了设置还是弹“文件行结束符已更改”
这不是 VSCode 配置失效，而是多个机制在打架，优先级顺序是：.gitattributes > 工作区 .vscode/settings.json > 用户 settings.json > EditorConfig 插件规则。
- 检查项目根目录有没有
.gitattributes，里面如果写了eol=crlf，VSCode 就会强制切回CRLF，哪怕你用户设置写了"\n" - 检查有没有
.editorconfig，其中end_of_line = crlf也会接管，且 EditorConfig 插件默认开启 - Git 全局设置了
core.autocrlf true（Windows 默认）？它会在git checkout时偷偷把LF转成CRLF，导致你一打开就“发现不一致” - 某些语言扩展（如 Python）会启用
editor.detectIndentation，间接影响换行符检测逻辑，建议显式关掉："editor.detectIndentation": false
真正稳住的关键，不是只调 VSCode，而是三者对齐：VSCode 设置 + .gitattributes + Git 全局配置。少一个，警告就可能反复弹出来。
