vscode 默认不自动转换换行符，files.eol 仅影响新行；需配合 trimtrailingwhitespace、insertfinalnewline 或手动“change end of line”才能重写现有行尾；git 的 core.autocrlf 优先级更高，推荐项目级 settings.json + .gitattributes + 统一 git 配置协同解决。
VSCode 默认不会自动转换换行符，必须手动配置或触发行为；保存时转 CRLF → LF 不是开箱即用功能，得靠 files.eol + files.autoSave 配合，且仅对当前文件生效，全局设置有陷阱。
为什么改了 files.eol 保存后还是 CRLF？
VSCode 的 files.eol 设置只影响新插入的换行，不重写已有行尾。也就是说：打开一个 CRLF 文件 → 改 "files.eol": "\n" → 按回车新增行是 LF，但原有行仍是 CRLF。
- 真正生效需配合“重新保存为”操作：
Ctrl+Shift+P→ 输入Change End of Line Sequence→ 选LF→ 再保存 - 或者启用
files.trimTrailingWhitespace+files.insertFinalNewline，它们会触发底层重写，间接让换行符统一 - Git 用户注意：
core.autocrlf优先级高于 VSCode 设置，若 Git 配置为true（Windows 默认），它会在检出时强制转 CRLF，掩盖编辑器行为
如何让保存时自动转 LF（CRLF → LF）？
VSCode 原生不支持“保存时自动转换换行符类型”，但可通过组合配置逼近效果：
- 设
"files.eol": "\n"（确保新行和重写行为用 LF） - 开启
"files.trimTrailingWhitespace": true（触发内容重写，顺便标准化换行） - 开启
"files.insertFinalNewline": true（末尾加 LF，强化 LF 主导） - 禁用
"files.enableTrash": false（避免误删原文件导致换行丢失） - 如果项目已混用换行符，建议先运行
sed -i 's/\r$//' *（Linux/macOS）或dos2unix批量清理，再启用上述设置
settings.json 全局 vs 工作区配置哪个更安全？
工作区级（.vscode/settings.json）更可靠。全局设置（用户 settings）会让所有项目强制 LF，可能破坏 Windows 下依赖 CRLF 的构建脚本（比如某些 PowerShell 或批处理工具）。
- 推荐在项目根目录建
.vscode/settings.json，内容为：
{
"files.eol": "\n",
"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true
}
- 同时配
.gitattributes（放在仓库根）：
* text=auto eol=lf
- 这样 Git 会统一处理换行，VSCode 和 Git 行为一致，避免“编辑器显示 LF，Git 提交变 CRLF”的错觉
插件能彻底解决自动转换吗？
插件如 Line Endings Auto Changer 或 Auto Fix Line Endings 可监听保存事件并调用 editor.action.changeEol，但存在兼容风险：
- VSCode 1.85+ 对 API 权限收紧，部分插件无法在保存钩子中修改文档内容
- 多光标编辑、未保存的脏状态下插件可能跳过转换
- 不如直接用 Git 的
eol=lf+ 工作区files.eol组合稳定 - 真要插件辅助，只建议用于一次性批量转换：
Ctrl+Shift+P→Convert Line Endings to LF（内置命令，无需插件）
换行符问题本质是协作链路（编辑器 → Git → CI/CD → 运行时）的协同问题，单点设置容易失效；最省心的做法是：项目级 settings.json + .gitattributes + 开发者本地 git config core.autocrlf input（macOS/Linux）或 false（Windows），三者对齐才真正稳。
