notepad++转换换行符最安全可靠的方式是使用菜单“编辑→eol转换”，右下角状态栏实时显示当前换行格式（如“windows (cr lf)”），不自动转换；批量转换应避免查找替换以防误伤空行或二进制内容，大文件建议另存为再覆盖；git提示已修改多因core.autocrlf设置与notepad++操作不一致所致。
Notepad++ 转换换行符最安全、最可靠的方式，就是用菜单里的 EOL 转换，别手抖去 查找替换 改 \r\n → \n —— 容易漏空行、破坏二进制内容、还可能误伤字符串里的字面量。
怎么看当前文件用的是哪种换行符
Notepad++ 右下角状态栏会直接显示，比如 “Windows (CR LF)” 或 “Unix (LF)”。它不猜测、不自动适配，显示什么就是磁盘上存的什么。如果你刚从 Git 拉下来一个文件，显示是 Unix (LF)，但你在 Windows 上用记事本打开却全挤成一行，那说明不是 Notepad++ 显示错了，而是记事本压根不认 \n。
怎么把 CRLF 批量转成 LF（比如改 .sh 脚本）
这是最常见需求：Windows 下写的 shell 脚本传到 Linux 里执行报错 bad interpreter: No such file or directory，八成就是换行符惹的祸。
Unix in a Nutshell同时涵盖了许多重要的、业界标准的开放源码工具 本书还完整地讨论了常用的shell(bash、ksh及tcsh)和重要元素如正则表达式，乃至旧式工具如sed、awk与vi。 Unix不是一个庞大的物体：它是一个综合体，而《Unix技术手册》则是将这一切合并在一起的一本书。 到底unix是什么?原始的unix源码是由sco拥有，unix注册商标是由open group拥有，而领先的仿unix系统则是gnu／linux、mac os x及solaris。这些版本所附的命令与选
- 打开文件后，点顶部菜单
编辑 → EOL 转换 → Unix (LF) - 转换完右下角立刻变成
Unix (LF)，不用保存就能看到效果 - 如果文件很大（>10MB），建议先
另存为新文件名再覆盖原文件，避免卡死或意外中断丢数据 - 别用
Ctrl+H查找\r\n替换为\n：空行、最后一行没换行、含\r的非换行内容都可能被误处理
为什么转完 Git 还提示“已修改”
Git 检出时按 core.autocrlf 设置偷偷做了转换，而 Notepad++ 修改的是工作区文件的原始字节 —— 它绕过了 Git 的感知流程。
- Windows 开发者建议运行：
git config --global core.autocrlf true（检出 CRLF，提交转 LF） - WSL/Linux 用户建议：
git config --global core.autocrlf input（只提交转 LF，不检出转换） - 项目已有大量混杂换行符？执行：
git add --renormalize .再提交，让 Git 重新统一处理暂存区 -
.gitattributes里写了* text=auto？那 Notepad++ 改完，下次git checkout很可能又被悄悄还原
怎么让新文件默认用 Unix 换行符
不想每次手动点菜单？可以设默认行为，但只影响新建文件，不影响已打开的旧文件。
- 点
设置 → 首选项 → 新建 → 保存 - 勾选 “
保存时自动转换到以下格式”，下拉选UNIX/OSX 格式 - 注意：这个设置对粘贴进来的旧内容无效 —— 粘贴时保留源格式，仍需手动
EOL 转换 - 如果同时在 WSL 和 Windows 下协作，建议团队统一配置
.gitattributes，比如加一行：* text=auto eol=lf
真正容易被忽略的点是：Notepad++ 从不读取 Git 配置，也不管你本地 core.autocrlf 设了啥。它只忠实地显示和写入字节。所以当你看到右下角写着 Unix (LF)，而同事说“我 git status 显示已修改”，那大概率不是 Notepad++ 的问题，而是两端 Git 行为不一致导致的视图错位。
