SetConsoleOutputCP(CP_UTF8)不生效的典型原因有三：源文件未保存为UTF-8无BOM、控制台字体不支持Unicode（需设为Lucida Console等）、printf/wprintf混用或未同步设置SetConsoleCP(CP_UTF8)。
Windows下SetConsoleOutputCP(CP_UTF8)不生效的典型原因
直接调用SetConsoleOutputCP(CP_UTF8)后中文仍乱码，大概率不是函数没执行，而是控制台字体、代码源文件编码、以及wprintf/printf混用这三者没对齐。Windows控制台默认使用ANSI代码页（如CP936），即使输出CP设为UTF-8，若字体不支持Unicode或字符串本身是GBK编码的窄字符，照样显示为“口口口”。
- 确保源文件保存为UTF-8无BOM格式（VS中右键文件→“高级保存选项”）
- 控制台字体必须设为支持Unicode的等宽字体，如“Lucida Console”或“Consolas”（右键标题栏→属性→字体）
-
printf只能正确输出UTF-8编码的char*；若用wprintf，则需配合SetConsoleOutputCP(CP_UTF8)+_setmode(_fileno(stdout), _O_U16TEXT)
用printf输出UTF-8字符串的最小可行方案
这是最轻量、兼容性最好的做法：不碰宽字符，只让printf把UTF-8字节流原样发给控制台，并确保控制台能渲染。关键在于跳过C运行时的代码页转换。
- 调用
SetConsoleOutputCP(CP_UTF8)启用UTF-8输出模式 - 调用
SetConsoleCP(CP_UTF8)（可选，影响输入，但建议同步设置） - 确保字符串字面量本身就是UTF-8编码——在VS里保存为UTF-8无BOM，或用
u8"你好"前缀（C++11起支持） - 不要用
std::cout ——它在MSVC旧版本中可能触发本地代码页转换；优先用<code>printf("%s", u8"你好")
#include <windows.h>
#include <stdio.h>
int main() {
SetConsoleOutputCP(CP_UTF8);
SetConsoleCP(CP_UTF8);
printf("%s\n", u8"✅ UTF-8输出正常：你好，世界！");
return 0;
}
_setmode(_fileno(stdout), _O_U16TEXT)和宽字符输出的坑
想用wprintf(L"你好")？那必须走宽字符通道，但这条路径更易出错。它要求整个链路都是UTF-16：源文件宽字符字面量、控制台输出模式、C运行时缓冲区模式三者严格一致。
-
_setmode(_fileno(stdout), _O_U16TEXT)必须在任何printf/wprintf调用前执行，且不能与窄字符IO混用（否则stdout缓冲区状态错乱） -
SetConsoleOutputCP(CP_UTF8)此时反而要禁用——因为_O_U16TEXT会让CRT把UTF-16转成UTF-8再发给控制台，双重转换导致乱码 - VS项目需关闭“SDL检查”（/GS-），否则
_setmode可能被拦截；同时确保main是wmain或显式调用SetConsoleOutputCP(CP_UTF8)无效时才考虑此路径
跨平台兼容性提醒：别在Linux/macOS上用SetConsoleOutputCP
这个API是Windows专属，Linux/macOS终端默认就是UTF-8，无需额外设置。如果代码要跨平台，务必用预处理器隔离：
立即学习“C++免费学习笔记（深入）”；
#ifdef _WIN32
SetConsoleOutputCP(CP_UTF8);
SetConsoleCP(CP_UTF8);
#endif
更隐蔽的问题是：某些IDE内置终端（如VS Code的集成终端、CLion的Terminal）可能模拟的是Linux行为，即使在Windows上也不响应SetConsoleOutputCP——此时应优先检查终端本身的编码设置，而非反复调试API调用顺序。
真正卡住的时候，先用chcp命令确认当前控制台代码页，再看SetConsoleOutputCP返回值是否为非零——失败往往意味着控制台已被其他程序锁定，或进程权限不足。
