应使用NFA而非strings.Contains，因其支持通配、分支和回溯等正则语义；需手动构建UTF-8感知的NFA，确保以rune为单位处理输入、用func(rune)bool定义转移条件、正确实现ε-closure，并限制状态数防爆炸。
为什么用NFA而不是标准库strings.Contains
因为你要匹配的是带通配、分支或回溯语义的模式（比如ab*c、a(b|c)d），而strings.Contains只做字面量子串查找，不支持正则语义。Go标准库的regexp包底层确实是基于NFA（回溯实现），但它是黑盒封装，无法控制状态迁移、无法嵌入自定义字符处理逻辑——比如你想在匹配过程中对每个UTF-8码点做预处理，或限制匹配深度，就必须自己构造NFA。
如何手动构建UTF-8感知的NFA状态转移表
Go中string底层是UTF-8字节序列，但NFA的输入单位必须是rune（Unicode码点），不能直接按字节走。常见错误是把[]byte当[]rune用，导致多字节字符被拆开匹配，状态跳转错乱。
- 先用
for _, r := range s遍历输入字符串，确保每次输入一个rune - NFA状态节点定义里，转移边的条件字段类型必须是
func(rune) bool，而不是byte或string - 构建ε-closure时，所有ε边（空转移）必须在rune输入前一次性收敛，否则UTF-8字符边界和状态并发性会冲突
- 示例：匹配
a.b（.匹配任意rune）的转移函数应写为func(r rune) bool { return r != 0 }，而非r != '\x00'——后者只判字节，漏掉U+1F600等辅助平面字符
避免NFA爆炸：UTF-8输入下的状态数失控问题
一个看似简单的模式如(a|b)*c在长文本上可能生成指数级状态组合，尤其当输入含大量连续合法rune（如中文段落）时，ε-closure和子集构造极易超时或OOM。
- 务必限制最大状态数（例如
maxStates = 10000），在addState时计数，超限直接panic或返回error - 禁用无界重复操作符的贪婪匹配，改用显式步进：
for i, r := range runes { current = step(current, r); if isAccept(current) { return i } } - 不要复用
regexp.Compile的结果来提取NFA结构——它的内部表示不公开，且针对PCRE优化，非UTF-8-rune粒度 - 测试时用
"\U0001F600\U0001F601\U0001F602"（emoji序列）比用"abc"更能暴露rune边界bug
实际运行时如何调试NFA匹配路径
标准库没有提供NFA执行轨迹输出，自己实现时最容易卡在“明明该匹配却没命中”，根本原因是rune输入顺序与状态机预期不一致。
立即学习“go语言免费学习笔记（深入）”；
- 在
step()函数入口加fmt.Printf("state %d + rune %U → ", from, r)，注意%U能正确显示UTF-8对应的码点 - 把输入字符串转成
[]rune再传入，避免在循环中反复调用len([]rune(s))——这个操作是O(n)，会掩盖真正的性能瓶颈 - 错误信息如
"no transition for rune U+4F60"比"match failed"有用得多；U+4F60是“你”字，能立刻定位到中文处理环节 - 别依赖
reflect.DeepEqual比较两个状态集合——rune切片顺序可能不同，要用sort.Slice预处理
真正难的不是写出NFA引擎，而是让每个rune都走对那条边。UTF-8本身没问题，问题总出在把rune当byte、把string当数组、把状态当原子值拷贝的地方。
