记录下今天花了1个小时才解决的问题：
Q：为什么新建的.c文件，在屏幕上汉字显示不出来，同一个工程，另一个任务就可以显示？
最后发现是.c文件的编码问题，MounRiver Studio新建文件的默认编码是GBK，而用utf-8保存.c文件就可以了，具体原因是？
问题根因：编码不匹配导致字符串二进制值错误
核心逻辑是：源码文件编码决定了硬编码汉字的二进制存储形式，而LVGL渲染中文字体时，期望接收的是与字库编码（如UTF-8/GB2312）匹配的二进制数据，两者不一致就会导致"找不到对应字形"，最终显示空白/乱码。
1. 先明确两个关键编码角色
| 编码角色 | 作用 |
|---|---|
| 源码文件编码（GBK/UTF-8） | 你在task03.c里写"任务3:GPIO测试"时，编辑器（MounRiver Studio）会按此编码将汉字转换成二进制字节存储到文件中； |
| LVGL中文字库编码 | 你的chinese_font_12m字体库是按某一编码（如UTF-8）制作的，仅识别该编码的二进制字节对应的字形； |
2. MounRiver Studio默认GBK导致的冲突过程
- 正常任务的.c文件 ：大概率是UTF-8编码，汉字
"任务3"会被转换成UTF-8格式的二进制（比如"任"=0xE4 0xBB 0xBB），和LVGL字库的编码匹配，能找到对应字形并显示； - 新建task03.c（默认GBK） ：汉字
"任务3"会被转换成GBK格式的二进制（比如"任"=0xC8 0xCE），LVGL字库按UTF-8规则解析这串字节时，无法匹配到任何字形，因此显示空白/乱码； - 改为UTF-8保存后 ：
task03.c里的汉字二进制回到LVGL字库能识别的格式，自然就能显示。
3. 为什么同工程其他任务正常？
其他任务的.c文件要么是：
- 手动改成了UTF-8编码；
- 工程初期创建时编辑器编码已调整过；
- 或字库本身兼容该文件的编码（比如早期字库是GB2312，但新文件GBK和GB2312虽兼容但工程编译链又强制按UTF-8解析，仍会冲突）。
4. 补充：MounRiver Studio的编码特性
MounRiver Studio（面向嵌入式RISC-V/ARM）默认对新建文件采用GBK编码（适配中文Windows的传统编码），但嵌入式LVGL/FreeRTOS等场景中，中文字库/编译链更常适配UTF-8（跨平台、无编码截断问题），这是嵌入式开发中典型的"编辑器默认编码"与"工程编码规范"不匹配问题。
延伸：为什么UTF-8能解决问题？
- UTF-8是国际通用编码，LVGL官方字库/第三方中文字库大多优先适配UTF-8；
- GBK是双字节编码（仅覆盖中文），UTF-8是变长编码（兼容ASCII+全语种），嵌入式编译链（如GCC）对UTF-8的支持更稳定，不会出现"单/双字节截断"；
- MounRiver Studio中修改文件编码为UTF-8后，源码里的汉字二进制与LVGL字库、编译链的编码解析规则完全对齐，字符串能被正确识别和渲染。
避坑建议
- 统一工程编码：在MounRiver Studio中设置"新建文件默认编码为UTF-8"（设置路径：
首选项→常规→工作空间→文本文件编码）； - 批量转换：对已有GBK编码的.c文件，用编辑器"另存为→选择UTF-8编码"覆盖保存；
- 验证方法：像之前测试那样，打印汉字字符串的十六进制值，对比正常文件的字节流，一致则编码匹配。
简单总结：汉字显示的本质是"编码→二进制→字库匹配"的链路，GBK保存的二进制无法被UTF-8字库识别，UTF-8保存则链路打通，因此能正常显示。