Go Participle 怎么用状态词法器处理引号内文本

处理 Participle 引号内文本时，关键是给引号内部单独配置词法规则：外部识别字段名和等号，内部识别普通文本、转义片段与结束引号；再让结构体语法强制匹配结束引号。不要把引号内部的空格继续按外部空白丢弃，也不要把词法识别误当作字符串解码。

官方地址：https://github.com/alecthomas/participle

明确配置文本的输入边界

考虑一个小型配置入口：用户输入 message = "hello = \"Go\""。业务希望获得字段 message 和包含等号、引号的完整值。如果始终按字段名、等号、空白拆分，hello 后面的空格和等号就会被赋予错误含义。

这里约定每次只解析一个赋值，字段名是 ASCII 标识符，值必须由双引号包围，可为空；内部允许普通 Unicode 文本，禁止真实换行。转义仅支持 \" 和 \\，不支持字符串插值、单引号、JSON 的 Unicode 转义或多个赋值。这是一个明确的小语法，不是通用配置格式替代品。

项目使用 Participle v2，导入路径带 /v2。在已有 Go module 中添加这个依赖，并把项目实际使用的版本记录到 go.mod；不要混用旧主版本的示例。下文代码是实现示例，不附带现场执行记录或性能结论。

分配引号内外的词法规则

把规则分成 Root 与 Quoted 两组。Root 中只有开引号带 Push 动作；Quoted 中只有闭引号带 Pop 动作。一个被 Escape 规则消费的转义引号属于片段内容，不是闭界符。普通文本表达式排除双引号、反斜杠、回车和换行，且用加号要求至少消费一个字符。

外部的小写 whitespace 规则忽略空格与制表符，而内部没有这条规则，因此引号内的空格仍属于 Text。内部的等号也没有单独规则，所以会留在 Text 中。不要为了复用把全部 Root 规则 Include 到 Quoted，否则很容易重新引入错误的内部语义。

这里把 Escape 放在内部规则前面，并让 Text 明确避开反斜杠。两者共同建立边界：合法转义独立成片段，未知转义没有规则兜底。不要使用“任意字符”规则吞掉所有失败输入，否则原本应该暴露的格式错误会被悄悄接受。

接入结构体语法与完整示例

完整示例如下。Assignment 的 Key 负责字段名和等号，Parts 负责匹配开引号、捕获零个或多个 Text/Escape 片段、匹配闭引号。闭界符没有问号，因此空值允许、缺少闭引号不允许。

package main

import (
    "fmt"
    "strings"

    "github.com/alecthomas/participle/v2"
    "github.com/alecthomas/participle/v2/lexer"
)

// 引号内不沿用外部的空白和等号规则。
var def = lexer.Must(lexer.Rules{
    "Root": {
        {"whitespace", `[ \t]+`, nil},
        {"Ident", `[a-zA-Z_][a-zA-Z0-9_]*`, nil},
        {"Equals", `=`, nil},
        {"Open", `"`, lexer.Push("Quoted")},
    },
    "Quoted": {
        {"Escape", `\\["\\]`, nil},
        {"Close", `"`, lexer.Pop()},
        {"Text", `[^"\\\r\n]+`, nil},
    },
})

// 开闭界符只匹配，片段集合保留原始拼写。
type Assignment struct {
    Key string `@Ident Equals`
    Parts []string `Open @(Text | Escape)* Close`
}

// 这里只解码规则允许的反斜杠和双引号，不能冒充 JSON 解码器。
func decodeParts(parts []string) string {
    var out strings.Builder
    for _, part := range parts {
        if part == `\"` {
            out.WriteByte('"')
        } else if part == `\\` {
            out.WriteByte('\\')
        } else {
            out.WriteString(part)
        }
    }
    return out.String()
}

func main() {
    // 使用同一份词法定义构建解析器。
    parser, err := participle.Build[Assignment](participle.Lexer(def))
    if err != nil {
        panic(err)
    }
    input := `message = "hello = \"Go\""`
    ast, err := parser.ParseString("config.txt", input)
    if err != nil {
        // 错误输入不进入业务处理。
        fmt.Println("解析失败:", err)
        return
    }
    fmt.Printf("key=%s raw=%q value=%q\n", ast.Key,
        strings.Join(ast.Parts, ""), decodeParts(ast.Parts))
}

Parts 使用字符串切片保存各个词法片段，便于分开处理 Escape 与 Text。连接片段得到的是去掉外围引号后的原始拼写，而 decodeParts 得到的是业务值。字段本身没有捕获 Open 和 Close，因此不会把两端界符混入结果。

例如输入中的 hello、等号及周围空格都归入普通片段，两个转义双引号由独立片段保存。fmt 的百分号 q 会给输出增加转义显示；看到打印文本中的反斜杠，不等于业务字符串里仍然含有那些反斜杠。

独立处理转义值与错误输入

解码函数只处理两个精确的 Escape 拼写，其他片段原样保留。这个限制来自前面的词法定义：只有成功解析后的 Parts 才传入它。如果你准备把它作为独立公共函数接收任意字符串，就需要另行设计输入错误返回，不能直接沿用这里的信任前提。

不要对已解码的值再次执行统一替换。连续替换容易把原本的双反斜杠改成单反斜杠后，又把后面的字符当成另一种转义。按片段解码能把每个被识别的 Escape 限制在自己的边界内。

错误输入要在解析入口终止：未知转义、实际换行、缺少结束引号及尾部多余内容都不应进入业务赋值。特别是缺少结束引号时，不应只看词法扫描有没有抛错；上面的语法把 Close 作为必需项，调用方必须检查 ParseString 返回的错误，不能拿可能存在的部分 AST 继续处理。

如果产品后来要求支持换行或插值，应先重新确定值语义，再扩展内部规则与语法。放宽 Text 或把所有反斜杠组合一律接受，只改变了识别范围，并不会自动补上正确解码或嵌套表达式支持。

整理规则速查与常见疑问

只用一条完整字符串正则可以吗？

对于没有插值和嵌套的简单双引号值，可以选择完整 String token。状态分组的价值在于明确内外规则并为后续复杂语法留出结构，而不是宣称简单字符串只有状态词法器才能处理。

内部空格为何没有消失？

忽略空白只出现在 Root 规则组。内部普通文本包含空格，因此它没有被识别成外部 whitespace。

空字符串是否需要特别分支？

不需要。Parts 的重复次数是零或更多，Open 后紧接 Close 就是合法空值，解码得到空字符串。

能直接把这套规则用于 JSON 吗？

不能。JSON 有自己的转义集合、控制字符和结构要求。本例只是受限的配置赋值语法，处理 JSON 应使用相应格式的解析器。

推荐保持三条边界：内部规则不要无意继承外部规则，语法明确要求闭界符，解码只实现承诺支持的转义。这样值中的空格、等号和引号才不会在不同阶段被反复误解释。

参考：官方状态词法器说明、lexer 包 API。