根本原因是编码错配，必须先执行File→Reopen with Encoding→Chinese (GBK)使文件正确解码为Unicode，再进行全局搜索；ST4中fallback_encoding已失效，推荐安装Codecs37插件辅助识别。
Sublime Text 全局搜索（Ctrl+Shift+F）出现中文乱码，根本不是搜索功能本身的问题，而是它在索引和匹配时，对文件内容的**编码解释错了**——比如把 GBK 编码的文件当成 UTF-8 解，导致搜索关键词“测试”被解析成几个无效字节，自然搜不到、也显示为方块或“锟斤拷”。
必须先让文件**正确解码进内存**，搜索才能基于真实文本进行。下面分场景说清怎么做。
全局搜索前，文件得先能“读对”
全局搜索依赖的是 Sublime 已加载的文件内容（即已解码为 Unicode 的字符串），不是原始字节。如果文件打开时就用错编码，内存里存的就是乱码，搜“中文”等于在一堆“口口口口”里找“中文”，注定失败。
- 打开乱码文件后，右下角显示的
UTF-8或Western (ISO 8859-1)只是当前解码方式，不是文件真实编码 - 立刻执行
File → Reopen with Encoding → Chinese (GBK)（或Chinese (GB2312)），只要中文显示正常，右下角变成Chinese (GBK)，就说明原始编码识别对了 - 别点状态栏直接切换编码——那只是临时重解，不保证后续搜索生效；也别点
Convert to UTF-8（老版本菜单），它会静默改写磁盘，不可逆
ST4 用户注意：fallback_encoding 已失效，换用 default_encoding_on_save
Sublime Text 4（Build 4100+）已彻底移除 fallback_encoding 字段。你在用户设置里写 "fallback_encoding": "Chinese (GBK)" 完全没用，不会影响任何文件的加载行为。
- 真正控制“保存时用什么编码”的是
default_encoding_on_save，但它只管写入，不管读取 - 读取阶段的兜底逻辑已由 ST4 内置的自动探测接管（支持 GBK/GB18030/Big5），但探测不准时仍需手动
Reopen with Encoding - 若你常开 GBK 文件，建议关闭
detect_encoding（设为false），避免它跳过 BOM 去硬试 GBK，反而把带 BOM 的 UTF-8 判成乱码
插件方案：优先选 Codecs37，慎装 ConvertToUTF8
ConvertToUTF8 在 ST4 上兼容性差，Package Control 里搜到的基本是过期镜像或恶意 fork，容易导致状态栏编码显示错乱、保存异常。
- 推荐手动安装
Codecs37：GitHub 搜索codex37/SublimeCodecs，下载 zip，解压后拖进Preferences → Browse Packages…打开的目录，重启生效 -
Codecs37支持 30+ 编码（含 GBK/GB18030/Shift-JIS），无需额外配置，加载即识别，且不干扰 ST4 原生逻辑 - 装完后仍要走
Reopen with Encoding确认——插件只是帮你更快识别，不能替代你判断原始编码
Reopen with Encoding 开始，而不是调搜索参数或换字体。 
