sublime text批量转换已打开文件换行符需分两步：先用ctrl+shift+p执行convert line endings to lf（大小写敏感），再执行save all持久化；漏掉任一步仅内存生效。
怎么批量转换已打开的多个文件换行符
Sublime Text 本身不支持“选中一堆文件直接改换行符”，所谓批量，是指对当前已打开的所有标签页统一操作。关键在于两步必须分开执行：先格式转换，再保存，漏掉任一环节都会白忙活。
- 用
Ctrl+Click（Windows/Linux）或Cmd+Click（macOS）多选标签页，或用Ctrl+P批量打开目标文件 - 按
Ctrl+Shift+P调出命令面板，输入Convert Line Endings to LF（注意大小写，不能输成全小写）并回车 - 再次调出命令面板，输入
Save All并回车——这步不可跳过，否则所有转换只存在内存里 - 若要转成 CRLF，命令是
Convert Line Endings to Windows，不是to CRLF
常见错误：点了状态栏的 CRLF → 选 Convert to Unix line endings → 看右下角变成 LF 就以为好了。其实没保存，关掉再开还是原样。
为什么不能用 Find in Files 正则替换换行符
有人在 Ctrl+Shift+F 里搜 \r\n 替成 \n，结果部分文件内容错乱甚至损坏。这不是正则写错了，而是换行符在不同编码和上下文里表现不一致。
-
\r\n在 UTF-16 文件里可能被解析为两个独立字符，替换后破坏字节对齐 - 混杂文件（比如既有
\r\n又有\r\r\n）用\r\n查找会漏掉脏数据 - 正则里的
\n在替换框中代表“换行符”，但最终写入是否真变成 LF，取决于当前文件的line_ending设置，不是绝对可靠
更稳妥的做法是：用 Find in Files 定位到所有目标文件路径，然后丢给终端命令处理，比如 macOS/Linux 下跑 dos2unix ./src/**/*.py。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
怎么让新文件默认用 LF，且团队协作不翻车
Sublime 的换行符设置分三层：当前文件真实格式、新建文件默认值、项目级覆盖规则。改错地方根本没用。想长期稳定，得配合 Git 和 EditorConfig。
- 在
Preferences → Settings – User中添加："default_line_ending": "unix"（新建文件才生效） - 但语法专属设置（如
Python.sublime-settings）或.editorconfig文件会覆盖该设置 - Git 层面才是根本：
.gitattributes中加* text=auto eol=lf，再配git config --global core.autocrlf input（macOS/Linux）或true（Windows）
只靠 Sublime 手动开、转、存几百个文件，效率低、易遗漏，且无法防止新文件再出问题——真正跨平台协作，必须从 Git 和项目配置入手。
怎么确认当前文件到底用的是哪种换行符
右下角状态栏显示的就是真实换行符类型：LF 或 CRLF。没显示？说明 Sublime 没识别出差异（比如空文件、全 ASCII 行末无换行），这时别猜。
- 按
Ctrl+Shift+P→ 输入Set Line Endings，看高亮项是哪个 - 装
HexViewer插件，查末尾字节：0A是LF，0D 0A是CRLF - 文件是只读状态（右下角标
RO），点击转换菜单会失效，需先解除只读或用管理员权限重开 Sublime
最容易被忽略的一点：某些 Git 检出的文件在 Windows 上默认带 core.autocrlf=true，即使你手动转成 LF 并保存，下次 git checkout 可能又还原为 CRLF。
