如果你用 Astro 做内容站、文档站、或者边缘 SSR（Cloudflare/Bun/Deno 等），你大概率踩过同一类坑：
astro dev 一切正常，上生产（workerd / edge runtime）就冒出奇怪的差异Astro 6.0 基本就是针对这些工程现实给出的系统答案。
下面我按「你为什么应该关心」的顺序，把官方发布文（Astro 6.0）里的重点更新拆开讲。
Astro 6.0 的升级，不是“多了几个功能点”，而是三条主线一起推进：
astro dev 大重构，开发阶段也能运行“你的真实生产 runtime”。同时还有一批 依赖升级与破坏性变更（Node 22、Vite 7、Zod 4、Shiki 4），以及三项 实验特性（Rust Compiler / Queued Rendering / Route Caching）。
astro dev：开发阶段跑“真实生产运行时”Astro 以前的 dev server，历史包袱很重：默认假设你在 Node.js 上开发。这在过去没问题，但当越来越多项目把 Astro 跑在 Cloudflare Workers、Bun、Deno 等非 Node 运行时上时，dev/prod 的“裂缝”就出现了：
结果就是经典的：“dev 没问题，上线才爆炸”。
Astro 6.0 的变化是：借助 Vite 的 Environment API，astro dev 现在可以在开发阶段运行一个“自定义 runtime 环境”。更重要的是：
这类升级最大的价值不在于“更快”，而在于减少环境差异带来的不可控风险。
workerd 贯穿开发 / prerender / 生产对 Cloudflare 用户来说，Astro 6.0 这段描述非常关键：
@astrojs/cloudflare adapter 会在 开发、prerender、生产 的每个阶段都运行 workerdAstro.locals.runtime workaround”一句话：Cloudflare 从“能跑”变成了“第一等公民”。
如果你做的是边缘 API / 内容站 + 边缘动态能力，这能直接提升稳定性与调试效率。
几乎每个站都会用自定义字体，但字体这件事非常容易被低估：
Astro 6.0 新增了内置 Fonts API，目标就是把这些“最佳实践”做成框架能力：
官方示例（配置）：
// astro.config.mjs
import { defineConfig, fontProviders } from 'astro/config'
export default defineConfig({
fonts: [
{
name: 'Roboto',
cssVariable: '--font-roboto',
provider: fontProviders.fontsource(),
},
],
})使用方式（在 Head 或 Layout 里）：
---
import { Font } from 'astro:assets'
---
<Font cssVariable="--font-roboto" preload />
<style is:global>
body {
font-family: var(--font-roboto);
}
</style>我对这个 API 的评价是：它不“酷”，但非常值钱。因为字体相关问题一旦散落在各个页面/组件里，长期维护成本会非常高。
Content Collections 从 Astro 2.0 起就是核心能力，但一直有一个限制：内容变更需要 rebuild。
Astro 6.0 把 Live Content Collections 做到 stable：
定义 live source（示例）：
// src/live.config.ts
import { defineLiveCollection } from 'astro:content'
import { z } from 'astro/zod'
import { cmsLoader } from './loaders/my-cms'
const updates = defineLiveCollection({
loader: cmsLoader({ apiKey: process.env.MY_API_KEY }),
schema: z.object({
slug: z.string(),
title: z.string(),
excerpt: z.string(),
publishedAt: z.coerce.date(),
}),
})
export const collections = { updates }在页面里请求时查询（带内置错误处理）：
---
import { getLiveEntry } from 'astro:content'
const { entry: update, error } = await getLiveEntry('updates', Astro.params.slug)
if (error || !update) {
return Astro.redirect('/404')
}
---
<h1>{update.data.title}</h1>
<p>{update.data.excerpt}</p>关键点在于：Live 与 build-time collections 可以共存。
这对内容站（尤其是 CMS 驱动、新闻/公告、产品更新日志）非常友好。
CSP（Content Security Policy）最常见的误解是：
“不就是加几个 header 吗？”
在框架里要把 CSP 做对，难点在于：
Astro 6.0 宣布 CSP API 稳定，并给出一个“从 0 到可用”的配置路径：
import { defineConfig } from 'astro/config'
export default defineConfig({
security: { csp: true },
experimental: { csp: true },
})（上面示例来自官方发布文；如果你想做更精细的指令、hash 算法、外部资源白名单，可以继续用更完整的配置对象。）
值得注意的是：Astro 还强调 CSP 能与它的 responsive images 特性协同工作（因为相关样式是 build-time 生成的，可被自动 hash）。
如果你在做面向公众的站点、文档站、或有用户输入（UGC）的页面，CSP 是非常“性价比高”的安全增强。
Astro 6.0 同时升级了几项核心依赖与运行时要求，属于“你升级前必须确认”的部分：
@astrojs/* 包统一使用 Vite 7<Code /> 组件以及 Markdown/MDX code blocks 的高亮astro/zod 导入，而不是 astro:content如果你的项目锁定了自定义 Vite 版本（pin 了 Vite），官方建议是：先把 Vite 升到 v7 或更高，再升级 Astro。
除了稳定功能，Astro 6.0 还带了三项实验性能力——它们更像是在为 6.x 乃至 Astro 7 的主线铺路。
.astro 编译器从 Go 走向 Rust）Astro 6.0 提供了一个新的实验编译器：Rust 版本的 .astro compiler（原本是 Go）。官方给出的承诺点是：
开启方式（官方示例）：
npm install @astrojs/compiler-rsimport { defineConfig } from 'astro/config'
export default defineConfig({
experimental: {
rustCompiler: true,
},
})Astro 过去的渲染是递归遍历组件树；Queued Rendering 是两段式：先遍历生成队列，再渲染。
import { defineConfig } from 'astro/config'
export default defineConfig({
experimental: {
queuedRendering: {
enabled: true,
},
},
})不同平台的 SSR 缓存做法不一致一直很烦。Astro 6.0 提供了一个“平台无关”的 route caching API：
memoryCache）：import { defineConfig, memoryCache } from 'astro/config'
export default defineConfig({
experimental: {
cache: { provider: memoryCache() },
},
})---
Astro.cache.set({
maxAge: 120,
swr: 60,
tags: ['home'],
})
---
<html><body>Cached page</body></html>更有意思的是：它还能和 Live Content Collections 联动，做到“内容变更 -> 自动失效相关缓存”。
官方给了两条路径：
# 推荐：自动升级（会尽量帮你处理迁移）
npx @astrojs/upgrade
# 手动升级
npm install astro@latest新项目：
npm create astro@latest我个人建议的升级顺序是：
npx @astrojs/upgradeworkerd 贯穿开发/生产会省掉大量调试时间）