1 分钟阅读
商业设计师的技术栈：为什么我选 Next.js + MDX
#Next.js#MDX#技术栈
作为一个「设计出身、也写代码」的人，选技术栈的标准很朴素：能不能让我把时间花在内容与体验上，而不是折腾工具本身。兜兜转转，我落在了 Next.js + MDX 上。
为什么是 Next.js
博客虽然简单，但对「呈现」的要求一点不低：SEO、首屏速度、图片优化、动效。这些恰好是 Next.js 的开箱能力：
- 静态导出——我的文章是纯内容，构建时全部预渲染成静态页面，部署到任何地方都快。
- 元数据——每篇文章都能生成独立的 OG、canonical、JSON-LD，这对内容的传播至关重要。
- 服务端组件——动效组件只在需要的地方标记
"use client"，其余保持零客户端 JS。
export function generateStaticParams() {
return getAllPosts().map((p) => ({ slug: p.slug }));
}为什么是 MDX
写作不该被 HTML 打断。MDX 让我在 Markdown 里自然书写，需要时又能插入组件、甚至代码块：
这是一段正文，下面是一段可交互的组件：
<SandTransitionImage src="/images/cover.svg" alt="封面" />代码高亮交给 rehype-pretty-code，用 Shiki 在服务端完成，主题还能精确匹配我的品牌色——朱红的关键字、奶油的变量名，代码块本身就成了设计的一部分。
内容层的极简设计
我不用重型 CMS，文章就是 content/ 目录下的 .mdx 文件，frontmatter 描述元信息：
---
title: "文章标题"
date: "2026-07-10"
tags: ["Next.js", "MDX"]
---用 gray-matter 解析，一个 getAllPosts() 就串起了列表、详情、标签、sitemap 和 RSS。版本控制、可迁移、无锁定，这就是我想要的。
结语
技术栈的选择，本质是价值观的选择。Next.js + MDX 让我可以把「写作」和「造体验」当成同一件事——而这，正是一个商业设计师最想要的状态。
工具应该退到幕后，让内容与体验站到台前。