不能直接用 strings.Index 做实时流检测，因为它要求完整字符串输入，而流式数据分块到达，可能在模式串中间截断导致跨块匹配失败；流式 KMP 通过保存并传递当前匹配长度 matchedLen 实现跨块连续匹配。
为什么不能直接用 strings.Index 做实时流检测
因为 strings.Index 要求输入是完整字符串，而流式场景下数据是分块到达的（比如网络包、日志行、传感器帧），中间可能恰好被切在模式串的边界上。例如匹配 "abababca"，若流中前两字节是 "abab"，后三字节是 "abca"，拼起来才完整，但单独查都找不到。
KMP 的 next 数组必须支持跨块重用
流式 KMP 的核心不是重写整个算法，而是把 next 数组的状态（即当前已匹配长度）作为上下文保存下来，传给下一块数据。每次调用时从该状态继续匹配，而不是重置为 0。
-
next数组本身只需预计算一次，固定不变 - 真正要传递的是当前匹配位置
matchedLen—— 它是每块处理后的返回值，也是下一块的起始状态 - 注意：不能把整块数据拼接后再跑 KMP，内存和延迟都不允许；也不能对每块独立跑，会漏跨块匹配
Go 实现的关键结构体与使用方式
推荐封装成一个可复用的检测器：
type StreamMatcher struct {
pattern []byte
next []int
matched int // 当前已匹配长度，跨块保留
}
func NewStreamMatcher(pattern string) *StreamMatcher {
p := []byte(pattern)
n := len(p)
next := make([]int, n)
for i, j := 1, 0; i < n; i++ {
for j > 0 && p[i] != p[j] {
j = next[j-1]
}
if p[i] == p[j] {
j++
}
next[i] = j
}
return &StreamMatcher{pattern: p, next: next, matched: 0}
}
func (m *StreamMatcher) Match(chunk []byte) (found bool, newMatched int) {
i, j := 0, m.matched
for i < len(chunk) && j < len(m.pattern) {
if chunk[i] == m.pattern[j] {
i++
j++
} else if j == 0 {
i++
} else {
j = m.next[j-1]
}
}
m.matched = j
return j == len(m.pattern), j
}
使用时每次拿到新数据就调用 Match，检查返回的 found 即可；newMatched 不需要手动维护，内部已更新 m.matched。
立即学习“go语言免费学习笔记（深入）”；
边界情况和容易踩的坑
实际部署中最常出问题的地方不是算法逻辑，而是状态管理：
- 多个 goroutine 并发调用同一个
StreamMatcher实例会覆盖matched—— 必须按流隔离实例，或加锁（不推荐，影响吞吐） - 如果某次
chunk为空，Match仍应返回当前matched，不能重置；空 chunk 在 TCP 粘包/拆包中很常见 - 当
pattern为空时，next数组生成会 panic；需在NewStreamMatcher中提前校验 - 匹配成功后，若想继续找下一个重叠匹配（如模式
"aa"在"aaa"中应报告位置 0 和 1），需将matched设为next[matched-1]而非 0 —— 这个逻辑是否启用取决于业务需求
流式 KMP 的复杂点不在算法本身，而在状态如何不丢、不错、不混；只要 matched 这个整数传对了，剩下的就是标准 KMP 循环。
