sublime text 保存时强制用 n 换行符需三步：①手动切换当前文件换行符为 unix (lf) 并保存；②在语法专属设置（如 python.sublime-settings）中添加 “default_line_ending”: “unix”；③配合 git 的 .gitattributes（eol=lf）和 editorconfig 统一团队行为。
如何让 sublime text 保存时强制用 n 换行符
Sublime 默认按系统原生换行符保存（windows 是 rn，macos/linux 是 n），跨平台协作时容易引发 Git 警告或脚本执行失败。解决方式不是靠“自动转换”，而是固定文件的换行符类型并锁定保存行为。
关键操作是修改当前文件的换行符设置，并启用全局默认策略：
- 打开文件后，点击右下角显示换行符的位置（如显示
Windows (CRLF)），点击它，选Unix (LF) - 立刻按
Ctrl+S（Windows/Linux）或Cmd+S（macOS）保存——此时已生效，且该文件后续所有保存都会保持n - 若想让新建文件也默认用
Unix (LF)，进入Preferences → Settings – Syntax Specific，在右侧 jsON 中添加："default_line_ending": "unix"
default_line_ending 放哪才真正生效
这个配置项必须放在「语法专属设置」里，而不是通用设置（Settings），否则对 Python/JS 等不同语言文件无效。Sublime 会优先读取语法绑定的设置，比如你正在编辑 main.py，它实际加载的是 Python.sublime-settings 的合并结果。
正确做法：
- 打开任意 Python 文件 →
Preferences → Settings – Syntax Specific - 右侧粘贴：
"default_line_ending": "unix" - 保存后，所有新打开的
.py文件都会默认用n；同理，为JavaScript、json单独配一次 - 不建议在通用
Settings里设，否则 Markdown 或配置文件可能被意外影响
Git 提交后仍报 CRLF 警告？检查 .gitattributes
Sublime 设置只管编辑和保存，Git 自己有一套换行符处理逻辑。即使文件里全是 n，如果 Git 认为你本地是 Windows，它仍可能在检出时偷偷转成 rn，再提交时又转回，造成脏 diff。
必须配合 Git 配置：
- 项目根目录加
.gitattributes文件，内容写：* text=auto eol=lf - 运行
git add --renormalize .重置所有文件的换行符状态 - 别依赖
core.autocrlf，它在跨平台团队中行为不稳定，eol=lf是更明确的声明
插件不是必需，但 EditorConfig 能统一团队习惯
单人用 Sublime 可以靠手动设 default_line_ending 解决，但多人协作时，每个编辑器行为不一致。这时候 .editorconfig 就比纯 Sublime 设置更可靠。
示例 .editorconfig：
root = true <p>[*] end_of_line = lf insert_final_newline = true需额外安装 Sublime 的 EditorConfig 插件（通过 Package Control），它会在打开文件时自动读取该配置并覆盖 Sublime 本地设置。注意：插件不会修改已有文件内容，只影响后续编辑和保存行为。
真正容易被忽略的是：换行符问题从来不是编辑器单方面的事，Sublime 设置只是其中一环，Git 配置和团队级 .editorconfig 才决定最终是否“稳”。