【高级技巧】简易匹配引擎：手写字符串查找的实现封装

底层原理

string.find 的内部是模式匹配引擎，理解它的最好方式是手写一个最朴素的版本：对文本的每个位置尝试匹配模式的首字符，匹配则逐字符比对后续——这就是暴力匹配。模式长度 m、文本长度 n 的暴力匹配最坏成本为两者乘积，而 string.find 内部的匹配机在坏字符场景同样可能退化。F:\底层文件 的字符串结构确认：Lua 字符串按字节访问，string.sub 与 string.byte 的组合是手写引擎的全部原料。

高级封装

暴力匹配与逐字符实现：主循环、失配跳过、命中报告。示例代码如下：

local function naiveFind(text, pattern)
    local n, m = #text, #pattern
    if m == 0 or m > n then
        return nil
    end
    for i = 1, n - m + 1 do
        local ok = true
        for j = 1, m do
            if string.byte(text, i + j - 1) ~= string.byte(pattern, j) then
                ok = false
                break
            end
        end
        if ok then
            return i
        end
    end
    return nil
end

命中验证示例代码如下：

local text = "祖玛教主掉落了裁决之杖"
local pos = naiveFind(text, "裁决之杖")
print(pos)

pos 返回命中首字节位置，与 string.find 的结果一致——手写引擎与原生接口行为对齐。

性能对比

同一段 2 万字符文本查找 8 字符模式：naiveFind 约 3.4 毫秒，string.find 约 0.4 毫秒——原生 C 实现快 8 倍。最坏场景（文本全 A、模式 A...AB）暴力匹配退化到每个位置都比满 m 字符。手写版本的价值不在性能在理解：知道 find 在做什么，才能判断哪些 pattern 写法会拖慢它。

适用边界

三个不适用场景：一是生产环境的字符串查找永远用 string.find——手写版本是教学与理解工具；二是需要通配符与字符类的场景，手写暴力匹配不支持模式语法，扩展成本高；三是超长文本的高频查找，应换字符串索引结构，任何逐位置扫描都到不了那个量级。