gse分词不准、搜索匹配不到关键词的根本原因是默认词典未覆盖业务专有名词，需显式加载UTF-8无BOM自定义词典、校验输入编码、用sync.Pool复用Segmenter实例并预热，否则切分错误、静默失败或并发panic。
gse分词不准，搜索匹配不到关键词？
根本原因是默认词典没覆盖业务专有名词，比如“小红书种草”“TiDB集群”会被切碎。gse启动只加载内置简体词典（约10万词），对未登录词靠规则硬切，结果就是“微信支付”变成“微信/支付”，搜“微信支付”自然匹配不上。
- 必须显式加载自定义词典：
seg.LoadDictionary("dict.txt")，且只能在seg.Segment()前调用一次；重复调用不报错但无效 - 词典文件必须是 UTF-8 无 BOM：Windows 记事本另存时选“UTF-8”，别选“UTF-8 with BOM”，否则静默失败、词典为空
- 每行格式严格为
词 词频 词性（空格分隔），例如：小红书种草 500 nz；词频远高于子词（如小红书 100 nz）才能强制成词 - 路径要用绝对路径或
filepath.Abs()拼接，避免go run和二进制运行时工作目录不一致导致文件找不到
为什么搜索模式下还是漏词？
gse没有类似结巴的cut_for_search专用接口，所谓“搜索模式”其实是靠seg.Cut(text, true)启用HMM+最短路径，但它默认输出所有可能切分，不是专为搜索优化的细粒度结果。
- 真正适合搜索的策略是：先用
seg.Segment([]byte(text))拿到[]gse.Segment，再手动过滤长度≥2的词，跳过单字和标点 - 别依赖
seg.Cut()返回的[]string——它会包含空格、句号、顿号等干扰项，直接用于ES或SQL LIKE匹配容易误判 - 想保留位置信息做高亮？必须遍历
[]gse.Segment，用s.Start和s.End字节偏移，别用strings.Split丢掉坐标 - 启用词性标注需提前调
seg.AddPos(true)，否则s.Pos恒为空字符串，无法按名词/动词过滤
并发搜索性能卡在单核？
gse.Segmenter实例不是并发安全的，复用同一个实例跨goroutine会panic或结果错乱。单线程跑满一个CPU核心，9.2MB/s在日志检索或API场景下很快见顶。
- 正确做法是用
sync.Pool缓存实例：var segPool = sync.Pool{New: func() interface{} { return new(gse.Segmenter) }} - 每次取用：
seg := segPool.Get().(*gse.Segmenter)；用完归还：defer segPool.Put(seg) - 别在全局变量里存一个
seg *gse.Segmenter然后多goroutine共用——这是常见panic来源 - 预热很重要：服务启动时先
seg.Segment([]byte("预热文本"))一次，让Trie树完成初始化，首请求不卡 - 如果启用了词频统计（
seg.WithFrequency(true)），内存占用多30%+，搜索场景建议关掉：seg.WithFrequency(false)
输入含繁体、乱码或GBK怎么办？
gse不做编码转换，遇到非法UTF-8字节会静默跳过整段，结果变短、无提示，线上搜不到内容却查不出错。
立即学习“go语言免费学习笔记（深入）”；
- 分词前务必校验：
if !utf8.ValidString(text) { /* 丢弃或转码 */ } - 繁体字（如“蘋果”）不会自动转简体，需前置处理：用
golang.org/x/text/transform做繁简转换，或github.com/mozillazg/go-unidecode转拼音再分词 - HTTP body或数据库字段可能混入GBK，别信前端说“传的是UTF-8”——打印原始字节
fmt.Printf("% x", []byte(text))比打印字符串更能暴露问题 - 转换推荐方案：
decoder := encoding.NewDecoder(unicode.UTF8)+strings.NewReader，别用string([]byte)强转，会丢数据
实际部署时最容易被忽略的是三件事：词典加载时机（必须在分词前）、UTF-8校验（不能省）、Segmenter实例复用方式（Pool不是可选而是必需）。任何一个环节出错，搜索就不可靠。
