gfm 不支持 native_spans 扩展。Pandoc 的默认 markdown 包括对 Pandoc 提供的大多数扩展的支持，包括默认情况下的 native_spans。
然而，正如文档所解释的那样：
Note, however, that commonmark and gfm have limited support for
extensions. Only those listed below (and smart, raw_tex, and
hard_line_breaks) will work. The extensions can, however, all be
individually disabled. Also, raw_tex only affects gfm output, not
input.
gfm (GitHub-Flavored Markdown)
pipe_tables, raw_html, fenced_code_blocks, auto_identifiers, gfm_auto_identifiers,
backtick_code_blocks, autolink_bare_uris, space_in_atx_header,
intraword_underscores, strikeout, task_lists, emoji, shortcut_reference_links,
angle_brackets_escapable, lists_without_preceding_blankline.
简单来说，native_spans 和 native_divs 扩展会解析原始 HTML 并将其转换为 Pandoc 的本地内部格式。如果输出格式支持，则可以将内容及其任何相关属性传递给输出格式。但是，如果没有使用扩展，则任何不直接支持 HTML 的输出格式都只会获得原始 HTML 的纯文本内容，这就是您看到的行为。
commonmark 和 gfm 都有严格的规范定义，因此似乎 Pandoc 不允许太多偏离这些严格规范的内容。因此，在使用 gfm 格式时，不支持 native_spans 和 native_divs 扩展。
文档 警告 关于此事：
由于pandoc文档的中间表示形式比其转换的许多格式更少表达，因此不应期望每种格式之间都有完美的转换。尽管从pandoc的Markdown到所有格式的转换力求完美，但可以预期从比pandoc的Markdown更具表现力的格式转换会有损失。
在这里需要记住的重要事情是，“pandoc的Markdown”（即
markdown格式）是唯一保证不会“有损”的格式。
gfm格式不是“pandoc的Markdown”，因此不具备该保证。
话虽如此，似乎应该支持native_spans扩展，即使它不是默认启用的，但是Commonmark规范（GFM扩展）完全重新设计了如何解析原始HTML。 可能，Pandoc需要重新定义解析原始HTML的方法以适用于commonmark和gfm格式。 因此，在原始HTML中工作的扩展名将无法使用替代解析器方法。 换句话说，任何在原始HTML上操作的扩展名（包括native_spans）都需要重写以适用于commonmark和gfm格式。 在发生这种情况之前，使用这些格式时将无法使用这些扩展名。 Pandoc是否计划在未来添加支持并不是我所知道的信息，并且超出了本讨论的范围。
