如何实现GitLab Flavored Markdown与pandoc支持格式的互转

目前没有开箱即用的原生支持GLFM的pandoc分支，成熟落地方案主要有三类，全部可以无缝对接现有pandoc工作流：

• 文本规则预处理/后处理方案
  这是生产环境最常用的方案，实现成本最低。GLFM和pandoc原生支持的GitHub Flavored Markdown（GFM）核心差异是可枚举的固定扩展语法，没有不可解析的黑盒逻辑，主要差异点包括：GitLab专属的告警块语法、Mermaid块的专属标识、Issue/MR快捷引用、内置目录标记、数学公式默认分隔符、任务列表扩展标记。
  转换流程：
  1. GLFM转pandoc支持格式：用简单的规则脚本（sed/awk/Python均可，通常几十行代码），把GLFM专属语法批量替换为pandoc可识别的GFM/原生Markdown语法，比如将:::tip/:::warning这类GitLab围栏告警块转换为pandoc支持的fenced div格式，将GitLab专属Mermaid标注转换为标准代码块，将快捷引用转换为普通Markdown链接，处理后的文件直接传给pandoc即可转成任意目标格式。
  2. pandoc支持格式转GLFM：先用pandoc将源文件转为GFM格式，再执行反向规则替换，把对应语法转回GLFM专属写法即可。
     这套方案完全可控，只需要适配实际用到的GLFM语法即可，不需要覆盖所有冷门扩展，不会出现未知的格式丢失问题。
• pandoc Lua过滤器集成方案
  如果不想维护独立的预处理脚本，可以把上述转换规则写成pandoc原生支持的Lua过滤器，直接嵌入pandoc转换流程。相比纯文本替换，Lua过滤器直接操作pandoc解析后的AST，识别精度更高，不会误匹配代码块、行内代码中的特殊字符。
  转换时直接在pandoc命令中挂载过滤器即可，例如GLFM转PDF的命令可以写为pandoc --lua-filter glfm-adapt.lua -f gfm input.glfm -o output.pdf；反向转GLFM时，可以在输出GFM的流程中挂载反向过滤器，直接将AST节点渲染为GLFM专属语法，不需要额外生成中间文件。
• 官方GLFM解析库适配方案
  如果对GitLab渲染一致性要求极高（比如需要100%对齐GitLab线上的渲染结果），可以基于GitLab官方开源的GLFM解析库做一层AST适配：将GLFM解析输出的原生AST转换为pandoc的内部AST结构，直接喂给pandoc做后续格式转换；反向转换时将pandoc输出的AST转换为GLFM渲染器支持的节点结构，再输出为标准GLFM文本。
  这套方案兼容性最高，但实现成本比前两种高，适合有批量文档转换需求的团队使用。

注意：GLFM的语法扩展会随GitLab版本迭代持续更新，不存在能一次性覆盖所有GLFM特性的通用转换工具，上述方案都支持按需迭代规则，长期维护成本很低。

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