notepad++新建文件默认编码是ansi（中文windows下为gbk），既不带bom也不是utf-8；需在“设置→首选项→新建”中手动选择“utf-8 without bom”才能使新建文件默认无bom。

Notepad++新建文件默认就是UTF-8带BOM？

不是。默认情况下，Notepad++新建的文件编码是ANSI（在中文Windows下实际为GBK），既不带BOM，也不是UTF-8。很多人误以为“点了UTF-8就自动无BOM”，其实它默认选的是UTF-8（带BOM）——那个选项名没写全，但行为就是带BOM。

• 打开设置 → 首选项 → 新建，检查右侧“编码”下拉菜单：若显示UTF-8（无后缀说明），那就是带BOM的；必须手动选UTF-8 without BOM
• 勾选UTF-8 without BOM后，后续所有新建文件（包括Ctrl+N、拖入新标签页）才真正默认无BOM
• 已打开的旧文件不会受此影响，仍需手动转换：右键状态栏编码 → 选择转为UTF-8无BOM格式 → Ctrl+S覆盖保存

为什么PHP/Shell/JSON文件一保存就报错？

因为BOM被当成了“开头不可见内容”。PHP解析器在<?php 前看到\xEF\xBB\xBF，会直接输出这三个字节，导致headers already sent；Shell脚本则因第一行不是#!/bin/bash而拒绝执行；JSON解析器遇到开头非{或[就直接报Unexpected token。

• 典型错误信息：Warning: Cannot modify header information - headers already sent、./script.sh: line 1: : command not found、JSON Parse error: Unexpected token
• Notepad++右下角显示UTF-8 ≠ 安全；只有显示UTF-8且状态栏无BOM字样（或用Hex Editor插件确认开头无EF BB BF）才算真正无BOM
• 批量修复：用文件 → 批量转换编码，目标编码选UTF-8 without BOM，勾选全部PHP/JS/JSON文件再点转换

怎么验证BOM真的被去掉了？

不能只信Notepad++右下角写的编码名。有些编辑器会“自我欺骗”——明明文件还带着BOM，界面却只显示UTF-8。

• 最可靠方法：安装Hex Editor插件（插件 → 插件管理 → 安装 Hex Editor），按Alt+Shift+H切换十六进制视图，看开头三字节是否为EF BB BF
• 命令行快速验证（Windows PowerShell）：Get-Content -Path file.php -Encoding Byte -TotalCount 3 | ForEach-Object { $_.ToString("X2") }，输出EF BB BF即存在BOM
• Linux/macOS下用xxd file.php | head -1，若首行含efbb bf，说明BOM仍在

自动保存时BOM又悄悄回来了？

常见于开启了文件 → 另存为或另存为副本操作，或者设置了“自动备份”但备份路径用了不同编码逻辑。更隐蔽的是：某些插件（如XML Tools）在格式化XML时会强制加BOM。

• 关掉自动加BOM的开关：在设置 → 首选项 → 新建里确认未勾选任何含BOM字样的选项；再搜files.autoGuessEncoding并启用，避免它“猜错”后偷偷重编码
• 禁用可能干扰的插件：比如XML Tools的“Pretty print (XML only)”默认会加BOM，可在插件设置中关闭Add BOM when saving
• 终极保险：把项目根目录下所有PHP/JS/JSON文件用脚本清一遍：find . -name "*.php" -exec sed -i '1s/^\xEF\xBB\xBF//' {} \;

BOM问题从来不是“保存一下就好”的小事——它藏在新建、另存、插件格式化、甚至Git提交的静默环节里。最麻烦的不是第一次处理，而是你以为清干净了，结果某次格式化XML或保存副本时，它又从缝隙里钻了出来。