sublime text不支持真正批量改换行符，右下角点击仅切换视图格式且不自动保存；需先执行convert line endings to lf/crlf命令，再手动save all才生效，否则修改仅存于内存。
Sublime Text 本身不支持“选中一堆文件直接批量改换行符”，所谓“批量”必须靠组合操作或外部工具实现，否则容易漏改、假替换、或改完没保存。
为什么右下角点 CRLF/LF 后没生效
点击状态栏的 CRLF 或 LF 只是修改当前视图的换行符类型，不会自动写入磁盘。常见现象是：点了 Convert to Unix line endings，右下角显示变成 LF，但一关再开又变回 CRLF——根本原因是没按 Ctrl+S（Windows/Linux）或 Cmd+S（macOS）保存。
- 该操作只影响当前文件，对其他已打开或未打开的文件完全无感
- 如果文件是只读状态（右下角标
RO），点击转换菜单会失效，需先解除只读或用管理员权限重开 Sublime - 某些 Git 检出的文件在 Windows 上默认带
core.autocrlf=true，即使你手动转成LF并保存，下次git checkout可能又还原为CRLF
如何真正批量处理已打开的多个文件
这是最接近“批量”的原生方案，但必须分两步：先转换格式，再统一保存。命令名严格区分大小写，输错就调不出。
- 用
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
用正则替换强行“跨文件批量改换行符”为什么危险
有人试图在 Find in Files（Ctrl+Shift+F）里搜 \r\n 替成 \n，结果部分文件内容错乱甚至损坏。这不是正则写错了，而是换行符在不同编码/上下文里表现不一致。
-
\r\n在 UTF-16 文件里可能被解析为两个独立字符，替换后破坏字节对齐 - 混杂文件（比如既有
\r\n又有\r\r\n）用\r\n查找会漏掉脏数据，得先用\r{2,}\n清理 - 正则里的
\n在替换框中代表“换行符”，但具体写入时是否真变成LF，取决于当前文件的line_ending设置，不是绝对可靠 - 更稳妥的做法是：用
Find in Files定位到所有目标文件路径，然后丢给终端命令处理，比如 macOS/Linux 下跑dos2unix ./src/**/*.js
项目级换行符统一，别只靠 Sublime
如果你的目标是整个代码仓库统一为 LF，靠 Sublime 手动开、转、存几百个文件，效率低、易遗漏、且无法防止新文件再出问题。
- Git 层面加
.gitattributes文件，写入* text=auto eol=lf，让 Git 自动标准化换行 - 新建文件默认格式由
"default_line_ending": "unix"控制，但它对已有文件完全无效 - 真正要清洗历史文件，推荐终端命令：
find . -name "*.js" -exec dos2unix {} \;（Linux/macOS），或 PowerShell 中用Get-ChildItem -Recurse -Include "*.py" | ForEach-Object { (Get-Content $_.FullName) | Set-Content $_.FullName -Encoding UTF8NoBOM } - Sublime 的角色应是“验证和微调”：比如用 HexViewer 插件查某个文件末尾是不是真写了
0A，而不是把它当主力清洗工具
