Astro Starlog 主题实战:以 1_4.md 为核心的发布日志 Content Collections 内容管线【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro本文以 Astro 官方示例仓库中的 Starlog(发布日志主题)为场景,围绕内容条目 1_4.md 完整剖析一篇版本发布稿如何从 Markdown 文件、Frontmatter Schema 校验,走到动态路由渲染成静态页面的全过程。读完后你可以掌握:Astro Content Collections 的globloader 与 Zod Schema 如何约束内容结构、getStaticPaths与render()如何把内容条目转成路由页面,以及版本发布站点(Changelog)主题的标准目录组织方式,可以直接套用到自己的产品发布日志站点上。1. 内容入口:1_4.md 的完整结构与字段含义Starlog 是 Astro 仓库内置的一个发布日志(Release notes)主题示例,基于 Astro 与 Sass 构建,支持深色与浅色模式(见 README)。其内容层由 4 个版本条目组成,分别位于 src/content/releases/ 目录下:1_0.md、1_4.md、1_8.md、2_0.md。本文的主角1_4.md代表1.4 版本的发布稿,其完整原文如下:--- title: Introducing Nebulous 1.8! date: 2022-04-16 versionNumber: 1.4 description: This is the first post of my new Astro blog. image: src: ../../assets/starlog-placeholder-14.jpg alt: The full Astro logo. --- ## Go further with 1.4 [](https://link.gitcode.com/i/fedb040c36340088803528c5a732ea18) Hello, Nebulous enthusiasts! Its that time again—time for us to unveil the latest and greatest in our tech universe. Buckle up as we introduce you to the future of Nebulous: ### New Features Enhancements - **NebulaSync Quantum:** Prepare for a mind-blowing file syncing experience. Its faster, smarter, and more intuitive than ever before. - **NebulaAI Odyssey:** Welcome to the era of NebulaAI Odyssey—a journey into the boundless possibilities of artificial intelligence. From image manipulation to language translation, Odyssey empowers you like never before. ### Bug Fixes - Squashed even more bugs, making NebulaSync and other features more reliable than ever. - Streamlined data transfer processes for flawless file exchanges. - Extended support for older devices to ensure everyone enjoys Nebulous. - Elevating error handling to the next level, ensuring a hiccup-free experience. Thank you for being the Nebulous journey. Your feedback fuels our innovation, so dont hesitate to share your thoughts or report any hiccups with our dedicated support team. Together, were shaping the future of tech with Nebulous!逐段解读这份文件的技术要素:Frontmatter 部分(5 个字段):字段取值作用渲染时的消费方titleIntroducing Nebulous 1.8!页面标题传入 PostLayout.astro 的BaseHead用于title与 SEOdate2022-04-16发布日期,发布稿在列表页按时间倒序排列的依据由 Schema 中的z.coerce.date()转成Date对象,再经 FormattedDate.astro 格式化展示versionNumber1.4版本号,与文件名1_4对应在 PostLayout.astro 的version_wrapper区块中以大号version_number样式展示,列表页同样展示descriptionThis is the first post of my new Astro blog.摘要,用于 SEO meta传入BaseHead description{...}image{ src, alt }嵌套对象封面图及其可访问性描述src经内容集合的图片处理管线解析,image整体传给BaseHead输出 Open Graph 等标签值得注意的是image.src的相对路径写法:../../assets/starlog-placeholder-14.jpg。内容文件位于src/content/releases/下,向上两级回到src/,再进入assets/目录,即最终指向仓库中 starlog-placeholder-14.jpg 这张 1560×520 的横幅图。正文中的Nebulous 1.4 Release引用了同一张图,这是发布稿典型的头图 正文配图结构。正文部分遵循一份标准的版本发布稿骨架:##主标题(1.4 版本导语)、###两个固定分区(新功能与 Bug 修复)、结尾致谢。需要说明的是,正文里的 Nebulous / NebulaSync Quantum / NebulaAI Odyssey 是示例项目虚构的产品文案,并且从文件内容看,title沿用了模板占位文案(Introducing Nebulous 1.8!)、description也仍是 This is the first post of my new Astro blog.——这说明该文件是一份可运行的样板,落地到自己的项目时需要把标题、描述和正文逐条替换为真实发布内容,但 Frontmatter 的字段结构与正文分区骨架可以直接沿用。2. Frontmatter 如何被 Schema 校验:content.config.ts 逐字段解析1_4.md里的每个 Frontmatter 字段都不是自由文本,而是被 content.config.ts 中定义的内容集合(Content Collection)严格约束的:import { defineCollection } from astro:content; import { glob } from astro/loaders; import { z } from astro/zod; const releases defineCollection({ // Load Markdown files in the src/content/releases directory. loader: glob({ base: ./src/content/releases, pattern: **/*.md }), // Type-check frontmatter using a schema schema: ({ image }) z.object({ title: z.string(), description: z.string(), versionNumber: z.string(), image: z.object({ src: image(), alt: z.string(), }), // Transform string to Date object date: z.coerce.date(), }), }); export const collections { releases };(content.config.ts 中的releases集合定义)对照1_4.md的 Frontmatter,这段配置的每个部分都有明确的对应关系:glob({ base: ./src/content/releases, pattern: **/*.md }):globloader 以src/content/releases为基准目录,按**/*.md递归收集 Markdown 文件。1_4.md正是被这条规则命中的条目之一,1_0.md、1_8.md、2_0.md同属一个集合。从源码结构看,globloader 以相对路径去扩展名作为条目id,因此1_4.md的id推断为1_4,后文的路由也就以1_4结尾。schema: ({ image }) z.object({...}):参数解构出的image是 Astro 内置的图片 Schema 助手,用于src字段。它的作用不只是校验字符串——在构建时,被image()覆盖的图片路径会进入 Astro 的内容图片处理管线(可生成优化格式并支持srcSet),这解释了为什么 package.json 依赖了sharp ^0.35.0作为图片处理后端,而1_4.md里的image.src因此才能放心使用仓库内相对路径。date: z.coerce.date():把 Frontmatter 中的字符串2022-04-16强制转换为 JSDate对象。这是后续所有按日期排序按Date方法格式化操作的前提——如果漏掉coerce,页面里拿到的是字符串,toLocaleDateString之类的方法将不可用。versionNumber: z.string():纯展示字段,无类型转换,原样输出到页面。image: z.object({ src: image(), alt: z.string() }):嵌套对象 Schema,与1_4.md中两层缩进的 YAML 结构一一对应。alt必填的设计保证了发布稿头图在 SEO 与无障碍层面都有文本描述。Schema 的约束力体现在构建期:若某篇发布稿缺少versionNumber,或image少写了alt,构建会直接报错而不是静默产出坏页面。这是用 Schema 管内容相对裸 Markdown 的核心收益。3. 从 Markdown 到页面:getStaticPaths 与 render 的渲染链路1_4.md对应的详情页由动态路由 pages/releases/[slug].astro 承担,全文如下:--- import { getCollection, render } from astro:content; import Layout from ../../layouts/PostLayout.astro; export async function getStaticPaths() { const releases await getCollection(releases); return releases.map((release) ({ params: { slug: release.id }, props: { release }, })); } const { release } Astro.props; const { Content } await render(release); --- Layout {release} Content / /Layout渲染链路分三步:getStaticPaths()枚举路由:在构建时调用getCollection(releases)取回全部通过 Schema 校验的条目,把每一条映射为{ params: { slug: release.id }, props: { release } }。四个内容文件对应四条静态路径,结合前文对globloader 的id分析,可以推断1_4.md生成的最终 URL 为/releases/1_4。await render(release)编译正文:内容条目本身只是数据 源文件,render()负责在构建期把1_4.md的正文(包括## Go further with 1.4各分区与内嵌图片)编译成可插入组件树的Content组件,并支持对正文组件使用client:*指令。Layout {release}套用页面骨架:Content /被放入 PostLayout.astro 的slot /中。该布局先通过BaseHead title{release.data.title} description{release.data.description} image{release.data.image}消费 Frontmatter 生成 head 区,再在version_wrapper区块输出release.data.versionNumber(即 1.4)与FormattedDate date{release.data.date} /。外层div classpost single还带transition:persist transition:namepost指令,说明该主题启用了 Astro 的客户端路由过渡(页面切换时该区块保留、不闪烁)。由此可以完整回答1_4.md这个纯文本文件凭什么变成/releases/1_4页面:globloader 发现文件 → Schema 校验并类型化 Frontmatter →getStaticPaths用release.id占位生成路由 →render()产出Content→PostLayout组装 head、版本头与正文。4. 列表页与日期展示:排序、链接与 time 元素发布站点的首页 pages/index.astro 把所有版本稿汇总成 Changelog 列表,其中两处细节值得对照1_4.md来看:--- import { getCollection, render } from astro:content; import FormattedDate from ../components/FormattedDate.astro; import Layout from ../layouts/IndexLayout.astro; const posts await getCollection(releases); posts.sort((a, b) b.data.date - a.data.date); ---倒序排序:posts.sort((a, b) b.data.date - a.data.date)按日期降序排列。这一步只有在 Schema 中z.coerce.date()生效时才成立——b.data.date对Date对象求数值,而1_4.md的2022-04-16早于2_0.md的2022-07-01,所以 1.4 会排在 2.0 之后,形成最新在上的发布日志观感。条目链接:列表项以a href{/releases/${post.id}}生成,再次印证了1_4.md的入口地址是/releases/1_4;列表项内同时展示versionNumber与日期,并在ul classposts上声明transition:namepost,与详情页的过渡指令呼应。日期展示由 FormattedDate.astro 完成,它是一个带类型约束的time封装:--- import type { HTMLAttributes } from astro/types; type Props HTMLAttributestime { date: Date; }; const { date, ...attrs } Astro.props; --- time datetime{date.toISOString()} {...attrs} { date.toLocaleDateString(en-us, { year: numeric, month: short, day: numeric, }) } /time对1_4.md而言,date: 2022-04-16经coerce后,页面输出形如time datetime2022-04-15T...ZApr. 16, 2022/time:机器可读的 ISO 时间戳放在datetime属性,人类可读的Apr. 16, 2022放在标签文本里——这是发布日志类站点对可访问性 语义化时间的完整处理,也解释了为什么 Schema 里date必须是Date而不是字符串。5. 本地运行与验证Starlog 示例是一个可直接运行的独立工程,关键配置如下:astro.config.mjs:defineConfig({ site: https://example.com }),声明了站点地址(用于生成规范的绝对 URL,占位值落地时应替换为自己的域名)。package.json:依赖astro ^7.2.10、sass ^1.97.3、sharp ^0.35.0,要求node 22.12.0,提供四个脚本:dev(开发服务器)、build(静态构建)、preview(预览构建产物)、astro(通用 CLI)。在 examples/starlog 目录下执行:npm install npm run dev即可在开发服务器中打开/releases/1_4验证本文描述的链路:版本头(1.4)、Apr. 16, 2022日期、Go further with 1.4正文与横幅图均应完整呈现;npm run build构建时若某篇发布稿的 Frontmatter 违反 Schema(例如漏掉image.alt),构建会失败并提示字段名,这是验证第 2 节所述约束力的最直接方式。6. 迁移要点:把这套结构用到自己的发布日志如果你要基于 Starlog 的releases集合结构建自己的 Changelog 站点,从1_4.md这一条目可以提炼出四条实践约束:文件名即路由:globloader 以相对路径去扩展名作id(从源码结构看),文件名1_4.md决定 URL 为/releases/1_4;想让 URL 更友好(如/releases/v1.4),要么重命名文件,要么在getStaticPaths中自行映射slug。展示字段与数据字段分离:versionNumber这类纯展示字段单独成键,避免从title或文件名里正则解析版本号。日期一律走z.coerce.date():只要列表需要排序或time需要toISOString(),Schema 层的类型转换就是必选项,1_4.md与 index.astro 的排序逻辑正是这一组合的最小完整样例。图片字段用嵌套对象 image()助手:如1_4.md的{ src, alt }写法,src用相对内容文件的位置写仓库内路径,交给 Astro 的图片管线处理优化,同时以alt满足无障碍与 SEO 要求。整套主题的文件组织——内容集中在 src/content/releases/,集合定义在 content.config.ts,详情页在 pages/releases/[slug].astro,布局拆分为 PostLayout.astro 与 IndexLayout.astro——就是一个内容驱动发布日志站点的完整最小实现,可以直接作为模板目录结构参考。【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Astro Starlog 主题实战:以 1_4.md 为核心的发布日志 Content Collections 内容管线【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro本文以 Astro 官方示例仓库中的 Starlog(发布日志主题)为场景,围绕内容条目 1_4.md 完整剖析一篇版本发布稿如何从 Markdown 文件、Frontmatter Schema 校验,走到动态路由渲染成静态页面的全过程。读完后你可以掌握:Astro Content Collections 的globloader 与 Zod Schema 如何约束内容结构、getStaticPaths与render()如何把内容条目转成路由页面,以及版本发布站点(Changelog)主题的标准目录组织方式,可以直接套用到自己的产品发布日志站点上。1. 内容入口:1_4.md 的完整结构与字段含义Starlog 是 Astro 仓库内置的一个发布日志(Release notes)主题示例,基于 Astro 与 Sass 构建,支持深色与浅色模式(见 README)。其内容层由 4 个版本条目组成,分别位于 src/content/releases/ 目录下:1_0.md、1_4.md、1_8.md、2_0.md。本文的主角1_4.md代表1.4 版本的发布稿,其完整原文如下:--- title: Introducing Nebulous 1.8! date: 2022-04-16 versionNumber: 1.4 description: This is the first post of my new Astro blog. image: src: ../../assets/starlog-placeholder-14.jpg alt: The full Astro logo. --- ## Go further with 1.4 [](https://link.gitcode.com/i/fedb040c36340088803528c5a732ea18) Hello, Nebulous enthusiasts! Its that time again—time for us to unveil the latest and greatest in our tech universe. Buckle up as we introduce you to the future of Nebulous: ### New Features Enhancements - **NebulaSync Quantum:** Prepare for a mind-blowing file syncing experience. Its faster, smarter, and more intuitive than ever before. - **NebulaAI Odyssey:** Welcome to the era of NebulaAI Odyssey—a journey into the boundless possibilities of artificial intelligence. From image manipulation to language translation, Odyssey empowers you like never before. ### Bug Fixes - Squashed even more bugs, making NebulaSync and other features more reliable than ever. - Streamlined data transfer processes for flawless file exchanges. - Extended support for older devices to ensure everyone enjoys Nebulous. - Elevating error handling to the next level, ensuring a hiccup-free experience. Thank you for being the Nebulous journey. Your feedback fuels our innovation, so dont hesitate to share your thoughts or report any hiccups with our dedicated support team. Together, were shaping the future of tech with Nebulous!逐段解读这份文件的技术要素:Frontmatter 部分(5 个字段):字段取值作用渲染时的消费方titleIntroducing Nebulous 1.8!页面标题传入 PostLayout.astro 的BaseHead用于title与 SEOdate2022-04-16发布日期,发布稿在列表页按时间倒序排列的依据由 Schema 中的z.coerce.date()转成Date对象,再经 FormattedDate.astro 格式化展示versionNumber1.4版本号,与文件名1_4对应在 PostLayout.astro 的version_wrapper区块中以大号version_number样式展示,列表页同样展示descriptionThis is the first post of my new Astro blog.摘要,用于 SEO meta传入BaseHead description{...}image{ src, alt }嵌套对象封面图及其可访问性描述src经内容集合的图片处理管线解析,image整体传给BaseHead输出 Open Graph 等标签值得注意的是image.src的相对路径写法:../../assets/starlog-placeholder-14.jpg。内容文件位于src/content/releases/下,向上两级回到src/,再进入assets/目录,即最终指向仓库中 starlog-placeholder-14.jpg 这张 1560×520 的横幅图。正文中的Nebulous 1.4 Release引用了同一张图,这是发布稿典型的头图 正文配图结构。正文部分遵循一份标准的版本发布稿骨架:##主标题(1.4 版本导语)、###两个固定分区(新功能与 Bug 修复)、结尾致谢。需要说明的是,正文里的 Nebulous / NebulaSync Quantum / NebulaAI Odyssey 是示例项目虚构的产品文案,并且从文件内容看,title沿用了模板占位文案(Introducing Nebulous 1.8!)、description也仍是 This is the first post of my new Astro blog.——这说明该文件是一份可运行的样板,落地到自己的项目时需要把标题、描述和正文逐条替换为真实发布内容,但 Frontmatter 的字段结构与正文分区骨架可以直接沿用。2. Frontmatter 如何被 Schema 校验:content.config.ts 逐字段解析1_4.md里的每个 Frontmatter 字段都不是自由文本,而是被 content.config.ts 中定义的内容集合(Content Collection)严格约束的:import { defineCollection } from astro:content; import { glob } from astro/loaders; import { z } from astro/zod; const releases defineCollection({ // Load Markdown files in the src/content/releases directory. loader: glob({ base: ./src/content/releases, pattern: **/*.md }), // Type-check frontmatter using a schema schema: ({ image }) z.object({ title: z.string(), description: z.string(), versionNumber: z.string(), image: z.object({ src: image(), alt: z.string(), }), // Transform string to Date object date: z.coerce.date(), }), }); export const collections { releases };(content.config.ts 中的releases集合定义)对照1_4.md的 Frontmatter,这段配置的每个部分都有明确的对应关系:glob({ base: ./src/content/releases, pattern: **/*.md }):globloader 以src/content/releases为基准目录,按**/*.md递归收集 Markdown 文件。1_4.md正是被这条规则命中的条目之一,1_0.md、1_8.md、2_0.md同属一个集合。从源码结构看,globloader 以相对路径去扩展名作为条目id,因此1_4.md的id推断为1_4,后文的路由也就以1_4结尾。schema: ({ image }) z.object({...}):参数解构出的image是 Astro 内置的图片 Schema 助手,用于src字段。它的作用不只是校验字符串——在构建时,被image()覆盖的图片路径会进入 Astro 的内容图片处理管线(可生成优化格式并支持srcSet),这解释了为什么 package.json 依赖了sharp ^0.35.0作为图片处理后端,而1_4.md里的image.src因此才能放心使用仓库内相对路径。date: z.coerce.date():把 Frontmatter 中的字符串2022-04-16强制转换为 JSDate对象。这是后续所有按日期排序按Date方法格式化操作的前提——如果漏掉coerce,页面里拿到的是字符串,toLocaleDateString之类的方法将不可用。versionNumber: z.string():纯展示字段,无类型转换,原样输出到页面。image: z.object({ src: image(), alt: z.string() }):嵌套对象 Schema,与1_4.md中两层缩进的 YAML 结构一一对应。alt必填的设计保证了发布稿头图在 SEO 与无障碍层面都有文本描述。Schema 的约束力体现在构建期:若某篇发布稿缺少versionNumber,或image少写了alt,构建会直接报错而不是静默产出坏页面。这是用 Schema 管内容相对裸 Markdown 的核心收益。3. 从 Markdown 到页面:getStaticPaths 与 render 的渲染链路1_4.md对应的详情页由动态路由 pages/releases/[slug].astro 承担,全文如下:--- import { getCollection, render } from astro:content; import Layout from ../../layouts/PostLayout.astro; export async function getStaticPaths() { const releases await getCollection(releases); return releases.map((release) ({ params: { slug: release.id }, props: { release }, })); } const { release } Astro.props; const { Content } await render(release); --- Layout {release} Content / /Layout渲染链路分三步:getStaticPaths()枚举路由:在构建时调用getCollection(releases)取回全部通过 Schema 校验的条目,把每一条映射为{ params: { slug: release.id }, props: { release } }。四个内容文件对应四条静态路径,结合前文对globloader 的id分析,可以推断1_4.md生成的最终 URL 为/releases/1_4。await render(release)编译正文:内容条目本身只是数据 源文件,render()负责在构建期把1_4.md的正文(包括## Go further with 1.4各分区与内嵌图片)编译成可插入组件树的Content组件,并支持对正文组件使用client:*指令。Layout {release}套用页面骨架:Content /被放入 PostLayout.astro 的slot /中。该布局先通过BaseHead title{release.data.title} description{release.data.description} image{release.data.image}消费 Frontmatter 生成 head 区,再在version_wrapper区块输出release.data.versionNumber(即 1.4)与FormattedDate date{release.data.date} /。外层div classpost single还带transition:persist transition:namepost指令,说明该主题启用了 Astro 的客户端路由过渡(页面切换时该区块保留、不闪烁)。由此可以完整回答1_4.md这个纯文本文件凭什么变成/releases/1_4页面:globloader 发现文件 → Schema 校验并类型化 Frontmatter →getStaticPaths用release.id占位生成路由 →render()产出Content→PostLayout组装 head、版本头与正文。4. 列表页与日期展示:排序、链接与 time 元素发布站点的首页 pages/index.astro 把所有版本稿汇总成 Changelog 列表,其中两处细节值得对照1_4.md来看:--- import { getCollection, render } from astro:content; import FormattedDate from ../components/FormattedDate.astro; import Layout from ../layouts/IndexLayout.astro; const posts await getCollection(releases); posts.sort((a, b) b.data.date - a.data.date); ---倒序排序:posts.sort((a, b) b.data.date - a.data.date)按日期降序排列。这一步只有在 Schema 中z.coerce.date()生效时才成立——b.data.date对Date对象求数值,而1_4.md的2022-04-16早于2_0.md的2022-07-01,所以 1.4 会排在 2.0 之后,形成最新在上的发布日志观感。条目链接:列表项以a href{/releases/${post.id}}生成,再次印证了1_4.md的入口地址是/releases/1_4;列表项内同时展示versionNumber与日期,并在ul classposts上声明transition:namepost,与详情页的过渡指令呼应。日期展示由 FormattedDate.astro 完成,它是一个带类型约束的time封装:--- import type { HTMLAttributes } from astro/types; type Props HTMLAttributestime { date: Date; }; const { date, ...attrs } Astro.props; --- time datetime{date.toISOString()} {...attrs} { date.toLocaleDateString(en-us, { year: numeric, month: short, day: numeric, }) } /time对1_4.md而言,date: 2022-04-16经coerce后,页面输出形如time datetime2022-04-15T...ZApr. 16, 2022/time:机器可读的 ISO 时间戳放在datetime属性,人类可读的Apr. 16, 2022放在标签文本里——这是发布日志类站点对可访问性 语义化时间的完整处理,也解释了为什么 Schema 里date必须是Date而不是字符串。5. 本地运行与验证Starlog 示例是一个可直接运行的独立工程,关键配置如下:astro.config.mjs:defineConfig({ site: https://example.com }),声明了站点地址(用于生成规范的绝对 URL,占位值落地时应替换为自己的域名)。package.json:依赖astro ^7.2.10、sass ^1.97.3、sharp ^0.35.0,要求node 22.12.0,提供四个脚本:dev(开发服务器)、build(静态构建)、preview(预览构建产物)、astro(通用 CLI)。在 examples/starlog 目录下执行:npm install npm run dev即可在开发服务器中打开/releases/1_4验证本文描述的链路:版本头(1.4)、Apr. 16, 2022日期、Go further with 1.4正文与横幅图均应完整呈现;npm run build构建时若某篇发布稿的 Frontmatter 违反 Schema(例如漏掉image.alt),构建会失败并提示字段名,这是验证第 2 节所述约束力的最直接方式。6. 迁移要点:把这套结构用到自己的发布日志如果你要基于 Starlog 的releases集合结构建自己的 Changelog 站点,从1_4.md这一条目可以提炼出四条实践约束:文件名即路由:globloader 以相对路径去扩展名作id(从源码结构看),文件名1_4.md决定 URL 为/releases/1_4;想让 URL 更友好(如/releases/v1.4),要么重命名文件,要么在getStaticPaths中自行映射slug。展示字段与数据字段分离:versionNumber这类纯展示字段单独成键,避免从title或文件名里正则解析版本号。日期一律走z.coerce.date():只要列表需要排序或time需要toISOString(),Schema 层的类型转换就是必选项,1_4.md与 index.astro 的排序逻辑正是这一组合的最小完整样例。图片字段用嵌套对象 image()助手:如1_4.md的{ src, alt }写法,src用相对内容文件的位置写仓库内路径,交给 Astro 的图片管线处理优化,同时以alt满足无障碍与 SEO 要求。整套主题的文件组织——内容集中在 src/content/releases/,集合定义在 content.config.ts,详情页在 pages/releases/[slug].astro,布局拆分为 PostLayout.astro 与 IndexLayout.astro——就是一个内容驱动发布日志站点的完整最小实现,可以直接作为模板目录结构参考。【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
