不建议从零实现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("# Hellonnworld"), &buf) if err != nil { panic(err) } println(buf.String()) // 输出:
Hello
nworld
n }手动解析时如何安全处理 inline 强调标记
如果坚持手写（例如嵌入到已有 parser 中），重点不是匹配 * 或 _，而是遵守「左边界」和「右边界」规则：强调符必须前后紧邻非空白/非标点字符，且成对出现、不跨行。常见错误是用正则 *(.*?)* 导致贪婪匹配或忽略嵌套。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：扫描字节流，记录未闭合的强调符位置（
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 上。