常见错误是初始化时 panic: cannot find dictionary，因 gojieba 默认从当前目录找词典文件；应显式指定路径或使用 NewJiebaFromEmbed()。
gojieba 初始化时 panic: cannot find dictionary
常见错误是直接 gojieba.NewJieba() 就报错，提示找不到词典文件。这不是代码写错了，而是 gojieba 默认会从当前工作目录下找 dict/jieba.dict.utf8 等路径 —— 但你根本没放，或者路径不对。
实操建议：
- 用
gojieba.NewJiebaFromPath("your_dict_dir")显式指定词典目录（比如把官方词典解压到./dict后传入"./dict"） - 更稳妥的方式是用嵌入式词典：调用
gojieba.NewJiebaFromEmbed()，它直接用内置的精简词典，不依赖外部文件，适合打包部署 - 别信文档里“自动加载”的说法，gojieba v1.2+ 已默认禁用自动查找，必须显式传路径或用 embed 版本
分词结果里出现空字符串或异常切分
典型现象是 seg := jieba.Cut("我爱北京天安门") 返回一个含空字符串的切片，或者把“天安门”硬切成“天/安/门”。这通常是因为输入文本含不可见控制字符（如 \u200b、\ufeff）、换行符混在中间，或者用了错误的分词模式。
实操建议：
- 预处理必做：用
strings.TrimSpace()去首尾空白，再用正则regexp.MustCompile(`[\u2000-\u206F\u2E00-\u2E7F\u3000-\u303F\uf900-\ufaff]+`).ReplaceAllString("", "")清掉全角空格和 Unicode 格式字符 - 区分场景选方法：
Cut()是精确模式（适合搜索索引），CutAll()是全模式（适合粗粒度提取），CutSearch()是搜索引擎模式（带新词发现）；别拿CutAll()当默认用，它容易过切 - 中文标点会影响切分，如果业务允许，提前把顿号、逗号等替换成空格再分词，比让 jieba “猜”更可控
并发使用 gojieba 导致 segfault 或 panic: concurrent map read and map write
很多人把 *gojieba.Jieba 实例全局复用，然后在多个 goroutine 里直接调 Cut()，结果运行一阵就崩。这是因为 gojieba 内部缓存了临时状态（比如 DAG 构建过程中的 map），不是并发安全的。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 每个 goroutine 应该持有自己的
*gojieba.Jieba实例，不要共享；初始化成本很低，不用怕开销 - 如果真要复用（比如内存敏感场景），必须加
sync.RWMutex，且只在Cut()调用前后加锁 —— 注意不能锁住整个分词流程（比如包含 IO 的预处理） - 更推荐用对象池：
sync.Pool{New: func() interface{} { return gojieba.NewJiebaFromEmbed() }}，取用后记得归还，避免 GC 压力
自定义词典不生效，新增词始终被忽略
调了 AddWord("奥利给", 10, 0)，但分词结果还是“奥/利/给”。问题不在函数调用本身，而在时机和词性权重设置。
实操建议：
- 必须在首次调用
Cut()之前添加自定义词，一旦 DAG 缓存生成，后续AddWord()不会刷新缓存 - 第三个参数是词性（POS），设为
0表示“未定义”，某些版本会降权处理；建议填常用 POS 如"x"（字符串）或"n"（名词），用gojieba.AddWord("奥利给", 10, "x") - 如果词频权重不够高（比如原词典里已有“奥利”“给”两个独立词），新词需要更高频次（如
100）才能压倒原有切分路径
真正麻烦的不是加词或选模式，而是词典路径、并发模型、缓存生命周期这三个点交叉作用时，错误表现非常隐蔽 —— 比如本地跑得好好的，一上容器就挂，大概率是词典路径相对于容器工作目录变了，或者实例被意外复用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
