从Sapper迁移到SvelteKit时如何基于Markdown创建页面？

Sapper迁移到SvelteKit过程中，原有基于marked导入Markdown文件并渲染的逻辑失效，本质是SvelteKit基于Vite构建体系，Vite默认没有内置的.md后缀文件解析能力，无法直接识别项目内的Markdown文件导入请求。这类场景下不强制必须使用Vite插件，可根据迁移成本选择两种可直接落地的实现路径：

低成本迁移方案（无需引入额外Vite插件） #

适合想最大程度保留原有业务代码、降低迁移工作量的场景，操作逻辑和你之前Sapper时代的写法几乎一致：

• 用Vite原生的import.meta.glob能力全量扫描项目里存放博客文章的Markdown目录，配置时加上query: '?raw'参数，强制获取Markdown文件的原始纯文本内容
• 在博客动态路由的加载逻辑里，根据文章的slug匹配对应的Markdown文本，传入你之前一直在用的marked解析实例做HTML转换
• 转换后的HTML内容在页面组件里通过{@html}语法渲染即可，你之前写的marked自定义配置、语法扩展、自定义规则都可以原样保留，不需要做额外改动

关键踩坑提醒：不要直接沿用Sapper里import article from './xxx.md'的导入写法，SvelteKit下这种写法会触发Vite的未知文件类型报错，必须通过?raw参数声明才能拿到Markdown的原始文本。

深度整合方案（使用适配的Vite插件） #

如果后续你有在Markdown文章里嵌入Svelte组件、自动生成文章目录、统一做代码块语法高亮这类进阶需求，可以选择适配SvelteKit生态的Markdown加载Vite插件：

• 这类插件会在构建阶段直接把.md文件编译为可被识别的Svelte组件，你可以像导入普通Svelte组件一样直接导入使用
• 配置时只需要把插件加入svelte.config.js里的Vite插件数组即可，注意插件版本要和你当前使用的SvelteKit大版本匹配，避免出现构建冲突
• 这类插件支持比纯文本marked解析更丰富的Markdown扩展能力，但会额外增加构建依赖，对纯文本为主的普通博客场景来说性价比不高

选型建议：如果你的博客文章都是纯Markdown文本，没有嵌入组件的需求，优先选第一种无插件的实现方案，不仅迁移成本低，构建速度也不会受额外插件影响。

内容的提问来源于stack exchange，提问作者Matt Stobbs