不建议从零实现Markdown解析器，因CommonMark规范有20+边界case，goldmark等成熟库已稳定解决嵌套、缩进、HTML混合等问题；推荐用goldmark禁用非必要扩展并自定义渲染。

为什么不用现成库而自己写 Markdown 解析器

除非你只处理极简的 Markdown 片段（比如仅支持 **bold**、*italic*、`code` 和换行），否则不建议从零实现完整解析器。CommonMark 规范有 20+ 边界 case，比如嵌套强调、列表缩进对齐、HTML 内联混合等，blackfriday、goldmark 已经稳定维护多年。自己写容易在 ***abc*** 或 > > blockquote 这类嵌套场景产出错误 HTML。

用 goldmark 实现可控的简易解析（推荐路径）

goldmark 是目前最符合 CommonMark v0.30 的 Go 库，扩展性好、无 CGO 依赖、API 清晰。所谓“简易”，是指禁用不需要的扩展（如表格、脚注），并自定义渲染规则。

• 默认开启所有扩展，需显式关闭：用 WithExtensions() 传入空切片或按需排除
• 关键控制点在 goldmark.WithRenderer() —— 你可以继承 html.Renderer 并重写 RenderText、RenderStrong 等方法，避免生成 而改用 或添加 class
• 若只需纯文本提取（如预览摘要），直接用 parser.Parse(text) + 遍历 AST 节点，比生成 HTML 更轻量

package main
import (
"bytes"
"github.com/yuin/goldmark"
"github.com/yuin/goldmark/renderer/html"
)
func main() {
md := goldmark.New(
goldmark.WithExtensions(), // 不传任何扩展 → 只支持基础语法
goldmark.WithRenderer(html.NewRenderer(
html.WithUnsafe(), // 允许原始 HTML（如需保留 @@##@@）
)),
)
var buf bytes.Buffer
err := md.Convert([]byte("# Hello\n\nworld"), &buf)
if err != nil {
panic(err)
}
println(buf.String()) // 输出: 
Hello
\n
world
\n
}

手动解析时如何安全处理 inline 强调标记

如果坚持手写（例如嵌入到已有 parser 中），重点不是匹配 * 或 _，而是遵守「左边界」和「右边界」规则：强调符必须前后紧邻非空白/非标点字符，且成对出现、不跨行。常见错误是用正则 \*(.*?)\* 导致贪婪匹配或忽略嵌套。

• 正确做法：扫描字节流，记录未闭合的强调符位置（stack），遇到匹配符时检查栈顶类型是否一致、是否满足边界条件（如前一个字符不能是字母/数字）
• 特别注意：**a**b** 应解析为 ab**，而非整个 a**b
• Go 标准库 strings.Index 和 bytes.IndexByte 比正则更快，适合单次扫描

HTML 输出中容易被忽略的转义细节

Markdown 输入里的 、&、、> 必须转义，但已由 goldmark 的 html.Renderer 自动处理；真正易漏的是自定义渲染器里手动拼接字符串时：

• 不要直接 fmt.Sprintf("

  %s

  ", text) —— text 中的 & 会变成 & 双重编码
• 应使用 html.EscapeString(text)（来自 net/html）确保只转义一次
• 若允许用户输入 HTML 片段（如 ``），需配合 html.UnescapeString 或白名单过滤，不能简单放行

  复杂点永远在边界：AST 构建是否支持中断恢复、内联 HTML 是否影响后续解析、代码块缩进是否以 4 空格为唯一标准——这些在 goldmark 里已覆盖，自己写时最容易卡在某一个缩进差 1 空格的 case 上。