qt creator编码设置本身不报错，但保存、添加文件或msvc编译时易出错，根源是utf-8（无bom）与gbk/gb2312混用；改默认编码仅影响新建文件，已有文件需手动转码并添加bom或统一为gbk，.pro文件尤其敏感。
Qt Creator 编码设置本身不会直接报错，但错误往往出现在“保存文件”“添加文件到项目”或“MSVC 编译”环节——根源几乎全是编码不匹配，尤其是 UTF-8（无 BOM）和 GBK/GB2312 混用。
为什么改了编码设置还是报 C2001 或 Failed to add to Project？
因为 Qt Creator 的“默认编码”设置只影响新创建的文件，对已存在的 .pro、.cpp、.h 文件无效。这些文件仍保留原始编码，而 MSVC 编译器读取时会按本地代码页（如 GBK）解析 UTF-8 字节流，把中文的多字节序列误判为非法字符或换行符，触发 C2001；Qt Creator 在写入 .pro 时也会因编码不一致拒绝修改，弹出 Failed to add to Project。
- 仅改全局设置
Default encoding≠ 所有文件自动转码 -
.pro文件特别敏感：哪怕只有一行中文注释，且文件是 UTF-8 无 BOM，就可能让添加操作失败 - Qt Creator 右上角显示的编码，是它“当前加载所用的编码”，不是文件磁盘实际编码——两者可能不一致
怎么确认并统一现有文件的真实编码？
别猜，用工具看。Notepad++ 是最可靠的验证手段：
Qt Creator 18.0.2
下载
Qt Creator 18.0.2 Windows x86_64 历史版本安装包，适合需要旧版本 IDE、旧项目兼容、Qt/C++ 项目维护、构建套件配置和调试环境回退的用户使用。
- 用 Notepad++ 打开
.pro、.cpp、.h文件，右下角明确显示当前编码（如UTF-8、ANSI、GBK） - 若显示
ANSI，在简体中文 Windows 下基本等于GBK（代码页 936） - 若显示
UTF-8 without BOM，而你用的是 MSVC，这就是高危状态 - 不要依赖 Qt Creator 自带的“重新加载为…”菜单——它有时会错误识别，尤其对无 BOM UTF-8
MSVC 下最稳的编码组合是什么？
不是纯 UTF-8，也不是纯 GBK，而是 UTF-8 with BOM —— 它能同时满足 Qt Creator 和 MSVC：
- Qt Creator 识别 BOM 后，会严格按 UTF-8 解析，中文注释、字符串正常显示
- MSVC 看到 BOM（
EF BB BF）就知道这是 UTF-8，不再按 GBK 解析，C2001消失 - 设置路径：
工具 → 选项 → 文本编辑器 → 行为 → 文件编码 → Default encoding设为UTF-8，勾选Add BOM on save - 对已有文件：在 Qt Creator 中打开 → 右上角编码显示点击 → 选
UTF-8→ 点Save with Encoding（必须手动保存才生效） - 注意：
Add BOM on save必须开启，否则新建文件仍是无 BOM，问题复发
为什么有时候改成 GBK 反而更简单？
当你项目完全在 Windows + MSVC 环境下运行，且不涉及跨平台协作或 Git 历史混乱时，GBK 是兼容性最强的兜底方案：
- MSVC 默认按 GBK 解析源码，零配置即可编译中文字符串
- Qt Creator 设置
Default encoding为GBK后，新建文件、保存、添加到项目全部顺畅 - 风险点：Git 提交时可能被标记为二进制（GBK 不是标准文本编码），且 Linux/macOS 开发者打开会乱码
- 操作：全局设为
GBK，再批量用 Notepad++ 打开所有源文件 → 编码 → 转为GBK→ 保存 - 关键检查点：
.pro文件必须也转成 GBK，否则添加文件仍失败
真正麻烦的从来不是改一个设置，而是让所有文件、所有环节、所有参与方用同一套编码规则。BOM 是 UTF-8 在 Windows MSVC 上唯一可靠的“身份证明”，没它，编译器就当你是乱码。动手前先用 Notepad++ 看清每个文件的真实编码，比盲目调设置有效十倍。
