应按 rune 数划分逻辑块并转回 string，避免字节切分破坏 UTF-8 边界；regexp 实例须线程隔离，禁用全局复用；高亮必须基于原始字节偏移；并发数宜设为 min(块数, GOMAXPROCS×2)。
大文本分块时如何避免切分破坏 UTF-8 字符边界
直接按字节长度切分字符串会截断多字节 UTF-8 字符，导致 string 解析异常或高亮错位。Go 的 string 是字节序列，len(s) 返回字节数而非 rune 数，这是最常踩的坑。
- 用
utf8.DecodeRuneInString()或strings.Reader逐 rune 遍历，累计字节数直到接近目标块大小 - 推荐封装一个安全切分函数：先用
utf8.RuneCountInString()获取总字符数，再按 rune 数（而非字节数）划分逻辑块，最后用[]rune(s)[start:end]转回string - 若必须按字节限流（如内存敏感场景），在切点附近向后扫描至下一个合法 UTF-8 起始字节（即高位为
0xxxxxxx、11xxxxxx、10xxxxxx的合规组合），跳过截断风险字节
并发检索时如何避免正则表达式竞争与 panic
Go 的 regexp.Regexp 实例是**非线程安全**的，多个 goroutine 同时调用 FindAllStringIndex() 可能触发 panic（尤其在启用 CompilePOSIX 或复杂回溯模式时）。
- 每个 goroutine 必须持有独立的
*regexp.Regexp实例——不要复用全局变量或从池中取未加锁的实例 - 若搜索模式固定且高频，可用
sync.Pool缓存已编译的*regexp.Regexp，但需确保Get()后不被其他 goroutine 复用；更稳妥做法是每次regexp.Compile()（现代 Go 版本编译开销极低） - 避免使用
.*类贪婪匹配，改用[^\n]*?等明确边界限定，防止正则引擎回溯爆炸拖慢并发效率
高亮标记需保留原始字节偏移而非 rune 偏移
用户输入的搜索关键词位置、前端渲染或下游系统依赖的是原始字符串的字节偏移（例如编辑器光标定位、HTTP Range 请求）。若用 strings.IndexRune() 或 []rune 转换后计算，偏移量会错乱。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 所有匹配结果必须基于原始
string调用reg.FindAllStringIndex()获取[][2]int，其中每个[2]int是字节起止索引 - 拼接高亮结果时，用
s[:start] + "<mark>" + s[start:end] + "</mark>" + s[end:]，全程操作原始字节切片，不转 rune - 若需支持 Unicode 组合字符（如带重音符号的字母），正则应启用
(?U)标志，并确保关键词本身也按字节形式传入匹配
如何控制并发粒度防止 goroutine 泛滥
对 100MB 文本按 1MB 分块会启动百个 goroutine，加上调度开销和栈内存占用，反而比串行慢，还可能触发 OS 级线程限制。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.GOMAXPROCS(0)获取当前逻辑 CPU 数，将并发数设为min(块数, GOMAXPROCS*2)，通常 4–16 更稳 - 通过
chan struct{}实现简单信号量：启动前sem ，结束时 <code><-sem，通道容量即最大并发数 - 对超长块（如某块含大量换行但实际内容稀疏），可二次分片并递归提交到 worker channel，但需设置最小分片阈值（如 4KB），避免过度拆分增加调度负担
真正麻烦的是混合编码检测——如果文本来源不可控，UTF-8 / GBK / UTF-16 混杂时，分块前必须先做 BOM 判断或轻量编码探测，否则后续所有高亮都会偏移。这步没法绕开，得在入口处堵住。
