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或保存副本时，它又从缝隙里钻了出来。
