Sublime Text 的 default_line_ending 仅在语法专属设置（如 Python、JS 的 Settings – Syntax Specific）中生效，通用设置被忽略；右下角点击切换后需立即保存才写入 LF；Git 仍报 CRLF 警告需配合 .gitattributes 和 git add --renormalize .。
Sublime Text 无法“自动转换”换行符，只能固定默认类型并确保保存行为一致。想让所有新文件、新保存都用 LF（Unix），必须改语法专属设置，不是通用设置。
default_line_ending 放哪儿才真正生效
这个配置项只在「语法专属设置」里起作用。Sublime 编辑器会按当前文件的语法（比如 Python、JavaScript、JSON）加载对应语言的 .sublime-settings 文件，并合并用户设置。通用设置（Preferences.sublime-settings）里的 default_line_ending 被忽略。
正确操作路径：
- 打开一个
.py文件 →Preferences → Settings – Syntax Specific - 在右侧 JSON 中添加：
"default_line_ending": "unix" - 保存后，所有新打开的
.py文件默认就是 LF；同理，为.js、.json单独配一次 - 别给
Markdown或.env配，它们可能依赖系统原生换行符，强行统一反而出问题
右下角显示 Windows (CRLF) 但你想要 LF，怎么立刻生效
点击右下角换行符标识（显示 Windows、Unix 或 Mac Classic），选 Unix (LF)，然后马上按 Ctrl+S（或 Cmd+S）保存——这次保存就强制写入 LF，且后续所有保存都会保持 LF，无需插件。
注意：
- 这个操作只影响当前文件，不改变默认行为
- 如果刚切换完没保存就关了文件，下次打开还是原来的换行符
- Git 提交前仍报 CRLF 警告？那说明 Git 检出时又偷偷转回去了，得配
.gitattributes
为什么配了 default_line_ending 还是 CRLF？检查三个地方
常见失效原因不是配置写错，而是被更高优先级规则覆盖或环境干扰：
- 当前文件已带 BOM 或编码识别异常：Sublime 可能 fallback 到旧行为，先执行
File → Reopen with Encoding → UTF-8再试 - 项目根目录有
.editorconfig文件，且里面写了end_of_line = crlf—— EditorConfig 优先级高于 Sublime 设置 - 用了插件如
LineEndings或AutoSetSyntax，它们可能劫持保存逻辑，临时禁用插件验证是否冲突 - Git 的
core.autocrlf设为true（Windows 默认），它会在检出时强制转 CRLF，掩盖 Sublime 的 LF 设置
最易被忽略的一点：即使 Sublime 保存的是 LF，Git 也可能在工作区悄悄还原成 CRLF。所以 default_line_ending 只管编辑器这一端，跨平台协作必须配合 .gitattributes 和 git add --renormalize . 才算闭环。
