语法解析时空白字符通常应在语法单元开头还是结尾消费？

首先直接给结论：递归下降解析器组合子（包括FParsec）的工业界通用空白处理范式是基础词法单元（Token）负责消费自身匹配完成后的尾随空白，仅在整个解析器的顶层入口处消费一次全局前导空白，既不要让每个语法规则处理自身的前导空白，也不要无规则地零散在文法各处写空白消费逻辑。

两种常见错误思路的问题 #

你可能首先会想到两种对称的处理逻辑，实际用起来都会有明显的硬伤：

• 每个语法规则开头消费前导空白：首先会出现大量重复逻辑，多个规则串联时每个都要先跑一次空白匹配，性能浪费；其次遇到对空白位置敏感的语法（比如括号、运算符和操作数的相邻场景）很难做精准控制，回溯时还容易提前吃掉空白导致错误位置偏移，最终报错行号列号完全不准；最后文件最开头的前导空白虽然能被第一个规则处理，但文件末尾的残留空白没人接管，很容易出现「所有语法都匹配完了但剩了几个空格报解析失败」的低级问题。
• 每个语法规则结尾消费尾随空白：本质上和上面的问题对称，两个语法单元中间的空白会成为三不管地带，最后还是要给每个规则加前导空白处理逻辑，绕一圈回到同样的坑。

推荐方案的设计逻辑 #

这个方案完全适配FParsec的设计特性，也是FParsec官方文档推荐的写法，核心考量有三个：

1. 权责清晰，没有遗漏：全局入口处跑一次ws（你可以自己定义空白解析器，默认的spaces会匹配空格、制表符、换行，也可以扩展支持单行/多行注释）吃掉文件开头的所有前导空白；之后每一个基础词法单元匹配到自身内容后，立刻吃掉后面跟着的所有空白，下一个解析器永远从非空白字符开始匹配，不管是token中间的分隔空白还是文件末尾的残留空白，都会被最后一个token的尾随空白消费逻辑覆盖，不会有遗漏。
2. 避免回溯冲突：因为空白消费是在已经成功匹配到确定的token内容之后才执行的，不存在回溯时提前吃掉空白导致其他分支匹配失败的问题——这是解析器组合子场景下非常重要的点，很多人写Parser出莫名其妙的匹配失败，本质就是在可能回溯的分支前面放了空白消费逻辑。
3. 高层文法干净：你可以写一个通用的token包装函数，不用在高层的表达式、语句规则里到处塞空白处理逻辑：

   // 定义空白解析器，可扩展支持注释匹配
   let ws = spaces
   // 通用词法包装器：匹配对应规则后消费尾随空白
   let token p = p .>> ws
   
   // 所有基础词法单元全部用token包装
   let symbolIdentifier = token (identifier (IdentifierOptions()))
   let lparen = token (pchar '(')
   let rparen = token (pchar ')')
   let number = token (pfloat |>> float)
   

针对你举的... abc ...例子：开头的前导空白由顶层入口的ws负责消费，abc本身由symbolIdentifier的核心规则匹配，abc后面的空白由symbolIdentifier带的尾随空白逻辑消费，全程不需要前序语法单元单独处理空白，也不需要symbolIdentifier自己管前面的内容。

需要变通的特殊场景 #

这个规则不是死的，遇到两类场景需要单独调整：

• 解析对空白敏感的语法结构时，比如缩进块、字符串字面量、自定义的行内语法标记，这些结构的内部解析逻辑不要套通用的token包装，避免内部的有效空白被错误吃掉；等整个结构完整匹配完成后，再手动消费结构后面的尾随空白即可。比如解析双引号包裹的字符串时，从开头引号到闭合引号中间的所有字符（包括空格换行）都要原样捕获，等匹配到闭合引号后，再消费字符串后面的空白。
• 如果你写的解析器需要被其他规则嵌套调用，且嵌套场景要求前面不能有空白（比如解析标识符内部的特殊字符片段），就单独暴露一个不消费尾随空白的内部版本，不要直接用包装好的token版本。

一个小提醒：不要漏掉标点、运算符、括号这类短符号的token包装，很多人写Parser只给标识符、数字加了尾随空白处理，忘了逗号、分号、括号，最后遇到func (a,b)这种括号/逗号前面没空格的场景能正常匹配，加了空格就报错，本质就是这个原因。

内容的提问来源于stack exchange，提问作者aikixd