sublime 保存时自动补末尾换行符需同时确保换行符类型为lf且文件以单个\n结尾；仅设ensure_newline_at_eof_on_save: true只能补换行，不转换crlf为lf，也不去重空行，须配合手动切换右下角为unix(lf)或使用.editorconfig+editorconfig插件统一。
Sublime 保存时自动补末尾换行符：只开 ensure_newline_at_eof_on_save 不够
这个设置能解决“文件末尾没换行符”的问题，但不等于符合 POSIX 标准。POSIX 要求的是：最后一行必须以 \n（LF）结尾，且不能是 CRLF；而 ensure_newline_at_eof_on_save 只管“有没有换行”，不管“是什么换行”。它不会把 Windows 风格的 \r\n 转成 \n，也不会清理多余空行。
- 如果文件原本末尾是
\r\n，它照常保留，不符合 POSIX - 如果末尾已有空行（即两个
\n），它不会删掉多余的，导致结尾多一个空行 - 它不干预换行符类型，完全依赖你当前文件的
line endings设置（可通过右下角状态栏查看/切换）
怎么让 Sublime 真正输出 LF 结尾？必须手动统一行尾格式
Sublime 没有类似 VSCode 的 files.eol 全局强制设置，但你可以通过两种方式确保最终写入的是 \n：
- 保存前手动点击右下角状态栏的
CRLF或LF，选中LF再保存——这是最直接、100% 可控的方式 - 安装插件
LineEndings或EditorConfig，并在项目根目录加.editorconfig文件，写入：[*]\nend_of_line = lf
- 注意：
ensure_newline_at_eof_on_save只在保存时生效，它补的换行符类型，完全取决于你当前文件的行尾模式，不是它自己决定的
为什么补完换行后还是被 Git 报 warning：no newline at end of file？
常见原因是：你开了 ensure_newline_at_eof_on_save，但文件实际保存时用的是 CRLF（比如你在 Windows 上新建文件，默认就是 CRLF），Git 检查的是字节级内容，\r\n ≠ \n。
- 验证方法：用
xxd或 VSCode 的 Hex Editor 打开文件，看末尾字节是不是0a（LF）而不是0d 0a（CRLF） - 临时修复：在 Sublime 中按
Ctrl+Shift+P→ 输入Convert Line Endings to Unix→ 回车，再保存 - 长期规避：把
default_line_ending加进用户设置："default_line_ending": "unix"
，它会让新文件默认用 LF，但对已有文件不生效
顺手清理旧文件的末尾换行问题：别只靠保存时自动补
ensure_newline_at_eof_on_save 是“保存时检查并补”，它不会回溯处理已存在的文件。如果你有一堆历史文件末尾没换行，得主动操作：
- 批量转换行尾：选中多个文件 → 右键 →
Convert Line Endings→To Unix (LF) - 一键补末尾换行（针对无换行文件）：打开文件 → 按
End→ 按Enter→ 保存；或用正则替换$为\n，但要小心误伤已有换行 - 配合
trim_trailing_white_space_on_save一起开，避免补完换行后又带一堆空格，反而触发 lint 报错
真正容易被忽略的是：行尾格式和末尾换行是两个独立问题，一个配置搞不定。先定行尾（LF），再保末尾（\n），缺一不可。
