在Windows版Notepad++中，把CRLF改成LF可通过“编辑（Edit）→文档格式转换（EOL Conversion）→Unix (LF)”完成。先备份文件，再转换、保存并重新打开检查。这个操作针对当前文件的实际行尾，不是把长行在屏幕上折行，也不是转换UTF-8编码。
如果文件用于项目或数据导入，应先确认接收方要求LF还是CRLF；不要只因为电脑使用Windows就强制选CRLF。本文处理普通文本文件，不适用于直接修改Word、压缩包、图片等二进制文件。
先分清三个看起来相似的问题
CRLF由回车和换行两个控制字符组成，LF只有换行字符。两者都可以表示一行结束，但不同工具可能对行尾有特定要求。菜单中的Macintosh (CR)指旧式Mac文本格式，不代表现代macOS文件都应该选CR。
- 实际换行符：写入文件，影响脚本、版本比较或某些导入工具。
- 自动换行：只是长行在窗口中折成几段显示，调整窗口宽度时外观会变，不等于插入了新的行尾。
- 字符编码：决定字节如何解释成文字，中文乱码应另查编码，不能靠CRLF和LF互换修复。
例如脚本报出与行尾有关的提示，值得检查CRLF；如果中文变成问号，先参考Notepad++文件编码转换与防乱码说明。同一次修改同时改编码、删空格和换行尾，会让原因难以追踪，建议一次只处理一类问题。
打开行尾标记，确认文件当前状态
- 打开待处理文件，确认当前标签页文件名和路径，避免改错同名副本。
- 查看窗口底部状态栏中的Windows (CR LF)或Unix (LF)标识，记录当前状态。
- 进入“视图（View）→显示符号（Show Symbol）→显示行尾符（Show End of Line）”。不同中文语言包译名略有差异，可对照英文命令。
- 观察文件开头、中间、末尾，特别是从其他文件粘贴过的区域，看是否既有CR LF又有单独LF。
这些小方框是控制字符的可视标记，不是正文里真的写了“CR”“LF”几个字母。官方Views文档的Show Symbol说明解释了显示方式。查看标记本身不会改变文件内容，检查后可以关闭显示。
状态栏只能作为起点，不能凭一个标签就断言全文件没有混合行尾。对于长文件，重点查看不同来源拼接的位置；正式交付前，还应由项目的检查工具验证，而不是只抽查第一屏。
把当前文件统一成LF：操作与成功标准
- 先复制一份原文件，或用“文件→另存为”保存到测试位置。用于服务器或生产环境的脚本，不要直接覆盖线上版本。
- 确认激活的是副本标签页，进入“编辑（Edit）→文档格式转换（EOL Conversion）”。
- 选择“Unix (LF)”。如果接收方要求Windows行尾，则选择“Windows (CR LF)”，不要照搬示例。
- 查看行尾标记和状态栏，确认已变为预期类型。
- 保存文件，关闭该标签页，再从刚才保存的位置打开它，重新核对行尾、文字内容和文件名。
该菜单对当前文档各行生效，不会因为只选中了几行就自动变成“仅转换选区”。官方Editing文档的EOL Conversion说明明确了这一范围。需要保留某些行的特殊格式时，不要直接进行整篇转换。
成功应同时满足三个条件：保存后的副本仍是目标行尾，原有文字和行结构没有意外变化，接收工具能正常读取。只看到菜单点击过、标签页状态改变，并不足以证明磁盘上的文件已更新。
目标选项变灰、混合行尾，分别怎么处理？
已经显示LF，Unix选项却不能点击
如果文件本来就是LF，目标选项变灰通常不需要修复。先看行尾标记，有没有别的类型；纯LF文件不要为了“再转换一次”来回操作。
如果确实存在混合行尾，而目标项又变灰，官方文档给出的处理思路是：在备份副本中先切换成另一种行尾，再切回目标类型，然后保存和复核。不要把第一次中间转换的状态误当成最终结果。
转换后依然看到反斜杠转义文本
日志或JSON中可能保存的是反斜杠加字母组成的转义文本，而不是实际控制字符。EOL转换不会把这些普通字符自动解释成换行。先确认文件格式约定；随意替换可能破坏JSON字符串、正则表达式或路径。
保存后又变回CRLF
先检查是不是重新打开了原文件，或保存操作因只读、权限不足而失败。如果路径正确且确实保存过，检查是否有另一个编辑器、格式化工具或项目规则在保存、检出文件时重新规范行尾。不要先去修改全局设置，否则可能影响无关项目。
保留一次“保存前—重新打开后”的对照记录，包含文件路径、行尾状态以及是否运行过其他工具。这样能分清Notepad++中的操作没有落盘，还是后续流程再次改写了文件。
这些方法不应该优先尝试
不要先用全局替换删除所有回车。替换范围和搜索模式选错，可能把真正的分行合并掉。菜单已有专门转换功能时，优先使用它。去掉空行、把多行合成一行也不是转换行尾，两者会改变内容结构。
不要直接整文件夹覆盖。先用一个可恢复的样本验证，检查目录中是否包含二进制文件、生成文件和第三方源码。没有明确范围时，本文不建议批量转换。涉及版本库时，查看差异，确认变化集中在预期的换行符，而不是业务内容。
不要把行尾选择等同于操作系统选择。Windows电脑也能编辑LF文件；目标是匹配项目规范。团队协作优先遵守既有规范，避免多人提交时反复全文件改动。
常见问题
转换会把中文变成乱码吗？
正常的行尾转换不负责改变编码。若同时出现乱码，先停止覆盖保存，对照备份检查是否误操作了编码菜单或用错误编码打开文件。
只想让一行在屏幕上显示完整，需要转换吗？
不需要。那是窗口宽度、横向滚动或自动换行的显示问题。先调整视图，不要改动文件里的换行符。
文件最后一行没有LF，要手动加吗？
是否要求文件末尾有换行，应以项目规范为准。统一已有行尾和补一个末尾换行是不同操作，不能只看状态栏就认为两者都已经完成。
看到CR LF标记能直接删掉它吗？
不建议。标记对应实际分隔符，删除可能把相邻两行连起来。只想隐藏标记，关闭显示行尾符即可。
转换完成后能删除备份吗？
先让接收工具完成读取或测试，并确认差异没有意外内容变化。验证前保留备份，尤其是无法从版本库恢复的配置和原始数据。