sql文件表名带bom导致对象“找不到”：utf-8 bom（ef bb bf）被误作表名前缀，需用十六进制工具确认，重编码为utf-8（无bom）修复，导出时禁用write bom预防。
导入sql文件后表名莫名带不可见字符（bom）
mysql 或 postgresql 导入 .sql 文件时，如果表名或数据库名在客户端里显示正常，但执行 show tables 或 select * from `表名` 报错说“不存在”，大概率是文件开头藏了 utf-8 bom（\xef\xbb\xbf），它被当作了表名/库名的一部分——你看到的 user 实际是 user（前面有个看不见的三字节前缀）。
用十六进制编辑器快速定位BOM位置
BOM 只出现在文件最开头，且仅限 UTF-8 编码的文本文件。别靠肉眼或普通编辑器判断，直接上十六进制视图：
- Windows 推荐用
HxD（免费便携），打开文件 → 看左上角前 3 字节是否为EF BB BF - macOS / Linux 可用命令：
head -c 6 your_file.sql | xxd，若输出含efbb bf就确认存在 - VS Code 默认不显示 BOM，但装插件 “Hex Editor” 后右键 → “Open with Hex Editor” 即可验证
清理BOM不能只删开头三字节
直接删掉前三个字节看似简单，但可能破坏 UTF-8 编码完整性，尤其当文件里有中文、emoji 等非 ASCII 字符时，会导致后续内容乱码。正确做法是重编码：
- 用 VS Code 打开文件 → 右下角点编码名（如 “UTF-8 with BOM”）→ 选 “Save with Encoding” → 选
UTF-8（注意：不是UTF-8 with BOM） - 命令行批量处理（Linux/macOS）：
sed -i '1s/^\xEF\xBB\xBF//' file.sql仅适用于纯 ASCII 表名场景；更稳妥用iconv -f UTF-8 -t UTF-8//IGNORE file.sql > clean.sql - MySQL 客户端导入时加
--default-character-set=utf8mb4，能缓解部分解析问题，但不解决已写死在表名里的 BOM
预防比修复更重要：导出时就避开BOM
很多 GUI 工具（如 Navicat、DBeaver、甚至某些版本的 phpMyAdmin）默认导出带 BOM 的 UTF-8，这是根源。下次导出 SQL 时务必检查选项：
- Navicat：导出向导 → “高级” 页 → 取消勾选
Write BOM - DBeaver：导出数据 → “Encoding” 下拉选
UTF-8（不是 “UTF-8 with BOM”） - mysqldump 命令本身不加 BOM，但如果你用
echo "..." | mysqldump类似方式拼接，注意 shell 环境变量LANG是否设为en_US.UTF-8等带 BOM 倾向的 locale
BOM 在表名里不会报错提示，只会让对象“找得到却用不了”，排查时容易绕远路去查权限、大小写敏感、引号转义——其实问题就卡在那三个看不见的字节上。
