这篇文章并不是教程，而是一次从项目启动阶段出发的技术选型记录。

这个博客的目标并不是展示 UI 或练习框架，而是作为一个长期写作与技术沉淀的平台。

从架构角度来看，这个博客属于典型的 content-driven site（内容驱动型网站），其核心目标是在内容生产、性能与部署成本之间保持长期平衡。

因此技术选型需要满足：

长期可维护
内容优先
极低运维成本

所以技术选型并不是追求“最新技术”，而是追求“对当前项目总体维护成本最低的方案”。

🧭 技术选型概览

本博客的核心技术栈：

Framework：Nuxt 4
Content：@nuxt/content
UI：@nuxt/ui + Tailwind
i18n：@nuxtjs/i18n
Image：@nuxt/image + build metadata
Deploy & Hosting：Vercel
Analytics：Google Analytics (GA4)

🚀 为什么是 Nuxt 4，而不是纯 Vue + 自拼方案

相比纯静态生成（SSG）， SSR 在内容持续更新的 developer blog 中，能够提供更稳定的首屏性能与 SEO 表现。

如果从项目启动阶段做技术决策，Nuxt 4 对我最有吸引力的点有三条：

天然 SSR，博客类页面首屏性能与 SEO 表现更稳定
路由、数据获取、布局体系是约定式，减少样板代码
与内容系统、图片系统、i18n 生态衔接非常顺

如果换成纯 Vue 自己拼 SSR、路由分层、内容查询，会把大量精力浪费在“基础设施”而不是内容本身。

📝 内容层选 @nuxt/content

博客的本质是“内容产品”，所以我更看重：

Markdown 写作体验是否顺畅
内容是否可被 Git 追踪
多语言内容是否好管理

@nuxt/content 正好匹配：

内容直接落在 content/ 目录（如 content/blog/zh-CN）
通过 queryCollection("blog") 查询，和页面层衔接自然
结合 content.config.ts 能做基础字段约束，降低内容结构不一致带来的风险

它的价值不是“功能多”，而是让写作流和开发流统一在同一套仓库里。

这种方案本质上更接近 static-first architecture，避免引入 Headless CMS（如 Strapi、Contentful）带来的额外运行成本，更适合个人长期写作项目。

🎨 UI 层用 @nuxt/ui + Tailwind 4

我对 UI 层的诉求是：

先保证一致性，再做个性化
能快速出页面，同时保留改造空间

@nuxt/ui 负责提供高质量基础组件（如 UPageHero、UBlogPost、UCard）， Tailwind 4 负责定制和微调。

我希望采用一个长期可维护的模式：

在 app.config.ts 统一主题色、组件 slots
在 app/assets/css/main.css 用变量和渐变做品牌层样式

这样做的好处是：既不会陷入“从零造轮子”，也避免被组件库默认设计语言强绑定。

🌍 将 i18n 作为架构层的一等能力

这个博客一开始就按多语言站点设计，目标是支持 zh-CN / ja / en 三套内容。

@nuxtjs/i18n 在这里的价值很直接：

语言资源与页面路由同构
列表查询时可直接按 lang 过滤
页面文本和文章内容可以分别演进

通过按 locale 加载对应语言的文章内容，可以避免后期补多语言时的大规模重构。

🖼 @nuxt/image + 自定义图片元数据脚本

图片是博客性能的高风险区。

我会采用两层策略：

展示层使用 @nuxt/image
构建层用 scripts/gen-image-meta.mjs 扫描内容并生成宽高元数据

第二层很关键：提前写入尺寸信息可以有效减少布局抖动（Cumulative Layout Shift, CLS），移动端阅读体验会更加稳定。

也就是说，选型不是“只做压缩”，而是把图片问题前置到构建阶段解决。

博客性能问题往往不是运行时问题，而是构建阶段没有提前处理的问题。

☁️ 部署在 Vercel

我选择 Vercel 的考虑是：

对 Nuxt 项目部署流程友好，发布路径短
与前端项目协作简单，适合个人站持续迭代
配置环境变量与预览环境方便，便于快速验证改动

这类内容站的核心是“稳定上线 + 低维护成本”，Vercel 在这点上更匹配我的目标。

📊 Google Analytics (GA4)

内容站的持续优化离不开反馈闭环。在数据分析工具上，我选择的是 Google Analytics (GA4)，而不是依赖部署平台自带的统计工具。原因主要有三个：

GA4 在内容站分析方面更成熟，数据维度更完整
可以长期保存访问数据，适合持续观察内容趋势
与平台解耦，不依赖特定部署服务

对于个人博客来说，分析需求其实非常简单：

哪些文章被持续访问
用户主要来自哪些国家或地区
用户更关注哪些主题内容

GA4 的事件模型虽然比传统统计更复杂，但在博客场景中，只需要最基础的页面访问统计即可满足需求。

在 Nuxt 项目中接入 GA4 也比较简单，可以通过 nuxt-gtag 模块在应用层统一注入。

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ["nuxt-gtag"],
  gtag: {
    id: "G-XXXXXXXXXX",
  },
});

⚖️ 这套选型的边界与代价

技术选型本质上是权衡，而不是寻找“最优解”。这套也一样：

模块化程度高，升级依赖时要关注兼容性
多语言内容会增加维护量

但在“个人博客 + 可持续迭代”这个目标下，这些代价是可接受的。

✅ 结论

如果从开发起点看，这套选型的核心逻辑是：

用 Nuxt 4 统一 SSR 与工程骨架
用 @nuxt/content 保持写作与版本管理的一致性
用 @nuxt/ui + Tailwind 平衡效率和定制
用 i18n、Image、Vercel、Analytics 分别解决可扩展性、性能、部署和数据反馈

从整体来看，这套技术选型更像是一种 developer blog architecture 的实践，目标并不是追求技术复杂度或先进性，而是构建一套能够支撑内容长期稳定产生的系统。

Nuxt 4 + @nuxt/content + Vercel：个人博客的技术选型与架构思考