根本原因是find_in_files_charset配置项缺失或错误，需手动在Preferences→Settings–User中添加"find_in_files_charset": "UTF-8"并重启Sublime Text。
Sublime Text 3 搜索框（Find / Replace 面板）输入中文显示方块或问号，不是字体问题，也不是系统语言设置导致的——根本原因是 find_in_files_charset 配置项缺失或错误，它单独控制搜索时的字符解码逻辑，和文件打开编码完全无关。
搜索框乱码只跟 find_in_files_charset 有关
这个配置项不写在用户 Settings 里，也不在菜单里可点，必须手动加进 Preferences → Settings – User。它只影响 Ctrl+Shift+F（全局搜索）和 Ctrl+H（替换面板）里的中文输入与匹配行为。默认值为空，此时 Sublime 会用当前视图编码去解搜索字符串，但视图编码可能是 UTF-8，而你粘贴进来的中文剪贴板内容实际是 GBK 字节流，一解就崩。
- 必须显式设为
"find_in_files_charset": "UTF-8"（推荐）或"find_in_files_charset": "GBK"，取决于你日常搜索的文本来源 - 设成
"UTF-8"覆盖面最广：现代终端、IDE、浏览器复制的中文基本都是 UTF-8；设成"GBK"仅适用于从旧版 Windows 记事本、某些国产软件直接复制的文本 - 该字段不接受
"Chinese (GBK)"这类 UI 名称，只认标准编码名（UTF-8、GBK、GB2312），大小写敏感
find_in_files_charset 和 default_encoding 完全不互通
很多人以为改了 "default_encoding": "UTF-8" 就能解决搜索框乱码，其实没用。这两个配置走的是不同路径：default_encoding 管新建文件和显式保存；find_in_files_charset 是搜索模块独立加载的解码器，连 fallback 机制都不共享。
- 即使你已配好
"fallback_encoding": "Chinese (GBK)"，对搜索框零影响 - 即使你用
Reopen with Encoding把当前文件切到 GBK 显示正常，搜索框依然可能乱——因为搜索时根本不看当前文件编码 - 验证是否生效：复制一段中文（比如“测试”），Ctrl+Shift+F 粘贴进去，看是否显示为方块；改完配置后需重启 Sublime 才生效（热重载不触发该参数刷新）
Windows 下剪贴板编码差异是高频诱因
Windows 剪贴板本身不带编码标记，Sublime 在读取时依赖系统默认 ANSI 代码页（中文 Win10/11 默认是 936，即 GBK）。但如果你复制自 VS Code、Chrome 或微信，它们输出的是 UTF-8 字节，Sublime 却按 GBK 解，结果就是首字节 \xe6 被当做一个非法 GBK 字符，显示为 。
- 最稳方案：统一设
"find_in_files_charset": "UTF-8"，覆盖绝大多数现代工具链 - 若必须兼容老旧内部系统（如某 VB6 生成的文本），才考虑
"find_in_files_charset": "GBK" - 别试图用插件拦截剪贴板——Sublime 不开放该 API，所有“自动转码搜索框”的插件本质都是 hack 输入事件，稳定性差且新版常失效
真正容易被忽略的是：这个配置改完必须重启 Sublime，且它不继承任何其他编码设置。搜不到中文时先盯住这一行，比反复试 Reopen with Encoding 有效十倍。
