TL;DR
博客配置分三层:框架层(astro.config.mjs)、站点层(site.config.mjs)、内容层(content.config.ts)。每层职责不同,修改时不互相影响。
问题:单文件配置混乱
博客的配置内容很多:站点 URL、站名、导航菜单、社交链接、文章字段定义……全放在 astro.config.mjs 里,几百行难以维护。
改一个导航链接要翻遍整个文件,改坏了其他配置还不知道。
三层架构
第一层:框架配置(astro.config.mjs)
负责:Astro 框架本身配置—站点 URL、集成插件、适配器、构建选项。
import cloudflare from '@astrojs/cloudflare';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
site: 'https://blog.example.com',
output: 'server',
adapter: cloudflare(),
integrations: [mdx(), sitemap()],
});
修改场景:切换适配器、添加/移除集成。普通日常更新不需要动这个文件。
第二层:站点配置(site.config.mjs)
负责:站点信息—站名、博主名、导航菜单、社交链接、页脚内容。
export const SITE = {
name: '云图札记',
author: '公爵',
description: '一个技术博客',
};
export const NAV_LINKS = [
{ text: '首页', href: '/' },
{ text: '归档', href: '/archive' },
{ text: '关于', href: '/about' },
];
export const SOCIAL_LINKS = [
{ text: 'GitHub', href: 'https://github.com/yourname' },
{ text: 'RSS', href: '/rss.xml' },
];
修改场景:新增导航项、修改站名。日常最常见操作。
第三层:内容配置(content.config.ts)
负责:文章的字段定义—frontmatter 里每个字段类型和校验规则。
import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
description: z.string(),
pubDate: z.date(),
category: z.string().optional(),
tags: z.array(z.string()).optional(),
series: z.string().optional(),
seriesOrder: z.number().optional(),
}),
});
export const collections = { blog };
修改场景:新增文章字段(如 cover、draft)。不常改。
数据流向
content.config.ts → 定义文章字段
↓
site.config.mjs → 站点信息 + 导航 + 社交链接
↓
astro.config.mjs → 框架 + 插件 + 适配器
组件里引用:
---
import { SITE, NAV_LINKS } from '../site.config.mjs';
import { getCollection } from 'astro:content';
---
<h1>{SITE.name}</h1>
<nav>
{NAV_LINKS.map(link => <a href={link.href}>{link.text}</a>)}
</nav>
分层的好处
- 改站名不需要动框架配置
- 新增导航不会意外改适配器
- 代码审查更清晰:PR 里改了哪层
- 多环境部署:框架配置因环境不同,站点配置通常不变
写在
配置分层不是过度设计,是基本项目卫生。改一个东西不需要理解整个配置文件,这才是好架构。
延伸阅读
COMMENTS
种下你的想法
在花园里留下一条评论,和这篇文章一起生长。