编辑器预览、命令行导出、线上渲染最好共用一条 Markdown 流水线
Markdown 真正进入团队使用后，通常不会只经过一种渲染方式。编辑器里要实时预览，命令行里要批量导出，线上站点还要再做一次正式渲染。只要这三条链路的规则不一致，内容就会慢慢长出很多“本地看着没问题，上线以后才发现不对”的小坑。
一份内容经过三次解释，差异就会被放大
最常见的情况是：编辑器支持某个扩展语法，命令行导出不支持；命令行能正确处理 frontmatter，线上渲染又把某些字段忽略了；预览里图片路径是相对目录，发布后却要走 CDN 前缀。单独看每条链路都能工作，放在一起就变成维护成本。
这类问题之所以烦，是因为作者通常不会立刻发现。写作时看到预览正常，就默认内容已经“完成”；真正出错是在发布后，而那时排查范围已经从文章本身扩散到了构建脚本、静态资源和主题模板。
把 Markdown 解析当成一条可复用的内容管道
我更喜欢把 Markdown 处理拆成几个稳定阶段：读取原文、解析 frontmatter、补齐统一元数据、渲染标题和链接、最后再输出 HTML 或索引文本。这样编辑器预览、导出脚本和线上渲染即便不能完全共用代码，也可以共用同一套规则和样例。
最关键的是，别让每条链路自己偷偷补规则。今天编辑器里为了好看加一个标题处理，明天线上渲染为了 SEO 再改一个链接策略，时间一长就没人说得清“到底哪边算标准答案”。
frontmatter 约定越早统一越省事
很多发布差异其实不是 Markdown 正文的问题，而是 frontmatter 字段没有约定清楚。标题、描述、作者、标签、slug、草稿状态，这些字段如果每条链路的兜底规则不同，就会出现文章列表正常、详情页异常，或者详情页正常、搜索索引错误的情况。
与其在不同脚本里写一堆兜底，不如先把字段要求写死。哪些字段必填，哪些可以从文件名推断，哪些必须保持稳定，一开始定清楚，后面补内容时就不容易反复迁移。
发布前做一次“同文档多链路对照”很值得
我现在会更愿意留几篇结构复杂的文章作为样本：有目录、有代码块、有图片、有引用、有中文标题。每次改 Markdown 流水线，就用这几篇对照编辑器预览、导出结果和线上页面。只要这组样例稳定，说明内容基础设施还在可控范围里。
Markdown 看起来只是写作格式，但一旦接到站点系统里，本质上就是一条内容工程流水线。尽量让预览、导出和发布共用同一套约定，后面不管换编辑器还是换框架，都会轻松很多。