Markdown 引用: 保持层级清楚且发布后仍然好读
搜索 markdown blockquote 的真实需求，通常不是记住 >，而是把提示、引用回复、编辑备注放进页面后，仍然保持读者一眼能看懂。
Quick answer
单层引用用 >，只有在层级真的有意义时才加第二层 >>，然后在 Markdown Preview 里检查再发布，因为 blockquote 的问题往往出在缩进、余白、换行这些真实阅读效果上。
为什么 blockquote 要做渲染检查
blockquote 在源码里通常很稳定，但在阅读体验里很容易失衡。
- docs 里，普通补充可能看起来像严重警告
- 博客里，长引用可能比正文还重
- 知识库里，多层回复会让关系变得难追
所以最终判断不该停留在源码，而应该基于 Markdown Preview 里的实际显示。
可读性检查流程
基础写法
单层引用直接这样写:
> 发布前请先过一遍 preview。
对于简短提醒、引用句、补充说明，这通常已经足够。
多层引用什么时候值得用
只有在“回复关系”本身需要保留时，多层 blockquote 才值得保留。
> 发布备注: 上线前做一次最终 preview 检查。
>
> > 评审回复: 还要看一下移动端余白。
这类结构适合 docs 里的审核备注，或知识库里需要保留的短对话。
一个关于阅读体验的例子
好的引用应该帮助读者停一下，而不是让读者开始解码版式。
知识库摘要: 图片路径已经修正，但最终答案仍然需要做 preview，确认引用区域的留白是否自然。
编辑备注: 如果第二层开始变长，就把它改回正文。
如果第二层承载了太多解释，引用结构就会拖慢阅读。
渲染差异通常体现在哪
不同渲染器或主题下，blockquote 常见差异包括:
- 左侧 border 粗细不同
- 段落上下留白不同
- 多层缩进深度不同
- 窄屏下折行更拥挤
因此它虽然属于 Markdown 编辑语法 Hub 的语法簇，但最后必须靠 preview 判断是否真的可读。
引用开始变难读的信号
注意这些情况:
- 引用比周围正文还长
- 超过两层嵌套
- 多个段落堆叠后视线容易迷路
- 看起来像警告框或代码块而不是引用
遇到这些情况，通常改回正文或列表更清楚。
docs、博客、知识库里的使用方式
- docs: 提醒一个实现注意点，但不打断主流程
- 博客: 保留一句评论、结论或编辑备注
- 知识库: 呈现一段很短的上下文回复，同时保持答案主体易读
无论哪种场景，preview 都是判断“这是帮助理解，还是制造噪音”的最后关口。
Final takeaway
Markdown 引用不难写，难的是发布后仍然清楚可读。先在 Markdown Editor 写，再在 Markdown Preview 检查层级、余白和换行，再决定是否发布。
打开 Markdown Preview，在发布前确认引用层级和阅读体验。
Internal workflow links
- 下笔入口: Markdown Editor
- 渲染校验: Markdown Preview
- 语法导览: Markdown 编辑语法 Hub
FAQ
Markdown 里怎么写引用？
在行首写 >，后面接一个空格和引用内容。
多层引用怎么写？
继续增加 >，但只在层级真的有阅读价值时保留。
为什么发布后 blockquote 看起来不一样？
不同主题和渲染器会改变 border、余白、缩进和换行，所以最好在发布前做 preview。