sublime text 不自动检查或修复文件末尾缺失换行符，需手动补全或借助插件；状态栏仅显示换行符类型（lf/crlf），不反映末尾是否存在换行符；最可靠验证方式是用 tail -c 1 file.txt | xxd 查看末尾字节，输出为空即缺换行符。
Sublime Text 本身不自动检查或修复文件末尾是否缺失换行符（no newline at end of file），也不在保存时强制补全；它只处理行尾换行符类型（LF/CRLF），对“末尾有没有换行符”这件事完全不管——这是两个独立问题。
怎么确认文件末尾缺换行符
状态栏显示 LF 或 CRLF 只说明当前行尾格式，不反映最后一行是否以换行符结尾。常见现象是：Git 提示 no newline at end of file，但 Sublime 状态栏仍显示正常。
- 打开文件后，按
Ctrl+Shift+P→ 输入Set Line Endings，如果菜单高亮项是Unix (LF)或Windows (CRLF)，说明 Sublime 检测到了换行符；但如果整份文件只有一行且没换行，它可能根本识别不出，状态栏也不显示 - 最可靠方式是用命令行看末尾字节：
tail -c 1 yourfile.txt | xxd。输出为空表示缺换行符；输出0a（LF）或0d 0a（CRLF）则说明存在 - 在 Sublime 中启用
"show_line_endings": true和"draw_white_space": "all"后，最后一行末尾若没有 ↵ 或 ¶ 符号，大概率就是缺换行符
怎么手动补全末尾换行符
Sublime 不提供“保存时自动补换行符”的开关，但你可以用两种方式补：
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 光标移到文件末尾（
Ctrl+End），按一次Enter，再保存——这是最直接、零配置的做法 - 安装插件
FileHeader或TrailingSpaces，它们能高亮缺失换行符的行，但补全仍需手动回车 - 别依赖
Convert Line Endings to LF命令：它只替换已有换行符，不会在末尾插入新换行符
为什么 EditorConfig 不能解决末尾换行符缺失问题
.editorconfig 的 insert_final_newline = true 确实能控制是否插入末尾换行符，但它的生效前提是：EditorConfig 插件已安装、配置正确、且该规则被 Sublime 实际读取并应用。
- Sublime 默认不解析
.editorconfig，必须装EditorConfig插件（通过 Package Control） - 插件只在
on_load和on_pre_save事件中触发，如果文件已打开、未修改、也未保存，规则不会主动写入末尾换行符 - 即使配置了
insert_final_newline = true，它也只对新加载或修改后的文件生效；对已打开且未改动的文件无效 - 该设置和
end_of_line是解耦的：前者管“有没有”，后者管“是什么”
真正跨平台稳定的处理链路
靠 Sublime 单点配置无法根治，必须组合 Git + EditorConfig + 手动习惯：
- Git 层设
git config --global core.autocrlf input（macOS/Linux）或true（Windows），配合项目级.gitattributes文件声明* text=auto eol=lf - Sublime 用户设置加
"default_line_ending": "unix"，仅影响Ctrl+N新建文件 - 项目根目录放
.editorconfig，含insert_final_newline = true和end_of_line = lf，并确保插件已启用 - 日常编辑时养成习惯：保存前按
Ctrl+End+Enter，尤其改完配置文件、JSON、YAML 等对末尾敏感的格式
末尾换行符缺失不是视觉问题，是 Git diff 和某些解释器（如 Bash、Python shebang 脚本）的实际执行障碍；Sublime 不报错、不提醒，得靠人盯住最后一行。
