default_line_ending 配置仅对 ctrl+n 新建的空白文件生效，须写入 settings – user 的 json 中且值为小写"unix"、"windows"或"system"；右下角切换 eol 仅临时生效，需保存才写入磁盘；git 换行符警告需靠 .gitattributes 统一规范。
default_line_ending 放 Settings – User 里才生效
这个配置项只对 Ctrl+N 新建的空白文件起作用，且必须写在 Preferences → Settings – User 的右侧 JSON 中，值必须是小写字符串："unix"、"windows" 或 "system"。写错大小写（比如 "Unix"）或放在 Settings – Syntax Specific 以外的地方，都会被忽略。
常见错误现象：改完设置后新建文件仍是 CRLF（Windows 下尤其明显）——大概率是写进了默认设置、拼写错误，或用了中文引号。
-
"default_line_ending": "unix"→ 新建文件默认用 LF -
"default_line_ending": "windows"→ 新建文件默认用 CRLF - 它对已存在文件、拖进来的文件、从剪贴板粘贴的文本完全无效
右下角点了 LF 却没保存？换行符根本没变
点击右下角状态栏（显示 LF 或 CRLF 的位置）只是切换当前 View 的换行符类型，不写入磁盘。必须立刻按 Ctrl+S（Windows/Linux）或 Cmd+S（macOS）才能真正把 LF 写进文件。
常见错误现象：切换完就关 tab，下次打开还是原来的换行符；或者切换后忘了保存，Git 提交时仍报 CRLF will be replaced by LF。
- 这个操作只影响当前文件，不影响其他已打开或未打开的文件
- 如果文件里混有
\r\r\n这类脏数据，Sublime 不会自动清理，得先用正则\r{2,}\n替换 - 状态栏不显示？说明 Sublime 没识别出 EOL —— 可能是空文件、全 ASCII 无换行，或文件损坏
为什么 Git 还在报 CRLF 警告？Sublime 设置只是半截路
default_line_ending 只管编辑器端，Git 检出时可能又偷偷转回 CRLF。Windows 上默认 core.autocrlf=true，会强制把 LF 转成 CRLF 放进工作区，掩盖你 Sublime 的设置。
跨平台协作要真不报错，必须配 .gitattributes：
- 项目根目录加
.gitattributes文件，内容写：* text=auto eol=lf - 再执行
git add --renormalize .让 Git 重算所有文件的换行符 - 检查是否被
.editorconfig覆盖：如果项目里有end_of_line = crlf，EditorConfig 优先级更高
语法专属设置比全局设置更可靠
想让所有 .py、.js、.json 文件默认用 LF，直接在对应文件里设 default_line_ending 更稳。打开一个 .py 文件 → Preferences → Settings – Syntax Specific → 右侧加 "default_line_ending": "unix"。
这样做的好处是绕过 .editorconfig 和用户全局设置的干扰，也避免给 .bat 或 .env 这类可能依赖 CRLF 的文件误设。
- 别给 Markdown 或 .env 配统一 LF —— 它们有时依赖系统原生行为
- 插件如
LineEndings或AutoSetSyntax可能劫持保存逻辑，排查问题时建议临时禁用 - 文件带 BOM 或编码识别异常时，Sublime 可能 fallback 到旧逻辑，先
File → Reopen with Encoding → UTF-8再试
真正跨平台不报错的关键不在 Sublime 设置多细，而在于 Git 层面的 .gitattributes 是否到位 —— 编辑器只能保证你“存的是 LF”，Git 才决定“检出后还是不是 LF”。
