astrojs/ts-plugin 演进全解析Astro 语言服务背后的 TypeScript 插件【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astroastrojs/ts-plugin 是 Astro 官方提供的一款 TypeScript 插件让普通.ts文件也能获得.astro、.md、.mdx、.mdoc等文件的智能感知能力。本文以该插件在仓库中的 CHANGELOG.md 为主体脉络结合其源码实现与测试用例系统梳理它的功能边界、架构演进与典型配置方法。Astro 内容型网站的工程实践中TypeScript 文件与.astro模板文件常常相互引用例如在.ts中封装工具函数、再由模板消费。传统 TypeScript 语言服务不理解.astro语法导致跨文件跳转、重命名、引用查找全部失效。astrojs/ts-plugin 正是为了解决这一断层而生它把.astro代码转换成 TypeScript 可理解的虚拟文件并在必要时把 Astro 的环境类型注入程序使Astro.locals、Astro.self、内容集合 schema 等类型链条在编辑器与类型检查器中保持完整。插件定位与语言服务器分工但能力互补Astro 官方工具链分为两层astrojs/language-serverVolar 语言服务器支撑 VS Code 扩展与astrojs/ts-pluginTypeScript 服务端插件。README 明确说明使用官方 Astro VS Code 扩展时插件会被自动安装并配置见 ts-plugin/README.md。当你在纯 TypeScript 编辑器环境不依赖语言服务器或通过tsserver做跨文件分析时插件的价值就凸显出来——它负责的是 TS 文件看到 Astro 文件这一侧的能力。从 package.json 的依赖清单可以反推其内部结构astrojs/compiler将.astro源码转换为 TSX 的核心编译器astrojs/yaml2ts将 Markdown/MDX 等 frontmatter 的 YAML 内容转换为 TS 虚拟代码volar/language-core与volar/typescriptVolar 框架的虚拟代码与语言服务代理底座volar/typescriptcreateLanguageServicePlugin与createProxyLanguageService的出处vscode-languageserver-textdocument虚拟文本文档的构建工具。安装与最小配置通过createLanguageServicePlugin工厂导出的插件安装方式非常简单。在任意.ts/.js项目中执行npm install --save-dev astrojs/ts-plugin然后在项目的tsconfig.json中注册{ compilerOptions: { plugins: [ { name: astrojs/ts-plugin } ] } }配置完成后TypeScript 语言服务会在处理项目时加载该插件。它本身不含任何用户可调的选项参数属于安装即生效的插件所有智能感知逻辑均由插件内部自动完成。版本演进主线从编译器补丁到 Volar 一体化CHANGELOG.md完整记录了插件从预发布0.x到 1.x 正式版的历史。这条时间线本质上映射了 Astro 官方对编辑器工具化的两轮重构先是围绕astrojs/compiler做定点修补随后在 1.1.0 全面迁往 Volar 架构此后所有功能都以语言插件 虚拟代码的模式叠加。0.x能力奠基期0.2.0移除插件内置的astro.d.ts改为优先使用 Astro 包自带的环境类型避免双重声明冲突0.4.0完整支持在 JS/TS 中导入.astro的能力——包含 Astro 文件内的引用查找、.astro/.md/.mdx路径补全以及若干跳转定义/实现失效的修复0.4.2为.astro文件内的符号提供重命名支持0.4.3针对astro:content导入报错在错误信息中补充如何生成内容集合类型的指引。这一阶段确立了插件最核心的产品承诺TypeScript plugin adding support for .astro imports in .ts files同时支持跨.ts与.astro文件的符号重命名与引用查找。1.xVolar 化与能力跃迁1.1.0插件整体切换到 Volar 架构。CHANGELOG 中特别类比Volar 之于编辑器工具正如 Vite 之于构建——它成为插件稳定性、性能以及后续功能扩展的统一底座1.3.0新增Astro.self智能感知并开始为getStaticPaths自动推断props类型1.3.1在 1.3.0 基础上自动把getStaticPaths推断出的联合类型互相拍平flatten使存在分歧的props在解构前无需手动判别同时宣告支持 TypeScript 5.31.4.0重构 Astro 的 JSX 类型定义修复其他 JSX 框架用户的若干类型检查问题1.5.0升级至 Volar 2.0。由于属于底层架构更替CHANGELOG 明确请求用户上报回归问题1.8.0 / 1.9.0持续升级语言服务器所依赖的 Volar 版本其中 1.9.0 修复了script标签内智能感知的一系列问题1.10.0新增内容集合智能感知Content Collection Intellisense随附astrojs/yaml2ts升级至 0.2.0。这是插件此后几次大版本更新的主题词。将 1.10.0 与 1.10.11 之间的发布串联起来可以看到一条针对内容集合智能感知与 monorepo 场景持续打磨的完整迭代链。这里摘取几个高信息量的 Patch版本类型核心变更1.9.0 / 1.8.0 / 1.7.0 / 1.6.1 / 1.6.0 / 1.5.0Minor逐级升级 Volar 至 2.0修复缓存、TSX 解析、缺失 Prettier 导致的崩溃等1.10.0Minor新增 Content Collection Intellisense1.10.1Patch升级至 Volar 2.4.0 稳定版1.10.2Patch修复 Markdocmarkdoclanguage identifier内内容智能感知失效1.10.3Patch修复内容 schema 更新后未能正确重载的若干场景1.10.4Patch改善 TS 5.6 下的性能仍低于 5.5但已可正常使用1.10.5Patch更新内部 Volar 版本兼容更新版本 TypeScript1.10.9Patchtypescript依赖升级至 v6用户无需任何改动1.10.10Patch修复.ts中经Astro.locals链式访问的、位于.astro文件内的引用缺失问题1.10.11Patch修复 Astro 环境类型泄漏到无关 TS 项目的问题从源码看实现原理插件虽然以Patch节奏发布但其内部机制并不浅。以下机制共同构成了让 TS 理解 Astro的完整链路。入口按需组装语言插件在 src/index.ts 中插件通过 Volar 的createLanguageServicePlugin注册初始化逻辑分为三步调用isAstroProject判断当前目录是否属于 Astro 项目若成立则调用addAstroTypes注入环境类型尝试读取./.astro/collections/collections.jsonastro sync生成的产物拿到内容集合 schema 信息依据 schema 是否存在决定是否追加frontmatter 语言插件负责内容集合的 frontmatter 智能感知。这解释了 CHANGELOG 中 1.10.10 与 1.10.11 两个 Patch 的源码由来注入发生在项目初始化时因此判断是否 Astro 项目与注入哪些类型文件必须足够精确否则就会在 monorepo 场景引入副作用。环境类型注入与 monorepo 泄漏修复1.10.10 / 1.10.11src/astro-types.ts是 1.10.10 与 1.10.11 两次修复的主战场addAstroTypes会向上层目录逐级查找已安装的astro包将其中存在的env.d.ts与astro-jsx.d.ts两个文件追加进宿主getScriptFileNames()的返回结果。这是.ts文件中的 Go To References 能看到.astro内经Astro.locals触达的用法的关键——没有Astro全局声明Astro.locals.utils.toUpper()这类类型链无法解析引用自然丢失。实现同时用WeakSetts.LanguageServiceHost保证每个宿主只被装饰一次避免重复注入src/astro-types.ts。1.10.11 的泄漏问题则源于isAstroProject的判断标准。其逻辑是就近查找package.json若dependencies/devDependencies/peerDependencies中出现astro或在package.json同级目录下存在astro.config.*文件才判定为 Astro 项目。在 hoistednode_modules的 monorepo 中插件旧版可能从任意项目共享astro安装把env.d.ts/astro-jsx.d.ts注入到从未请求过它们的项目从而把types/node一并拉入。修复后只有真正依赖astro或拥有astro.config.*的项目才会被注入。对应的 test/units/astro-types.test.mts 直接用临时目录构造了三类 monorepo 项目依赖 Astro 的 docs、只依赖 React 的 frontend、仅含astro.config.mjs的 standalone逐一断言isAstroProject的判定结果同时又构造了Astro.locals.utils.toUpper()的 fixture验证注入前引用缺失、注入后引用可查——这是理解两次 Patch 行为最直观的可运行文档。.astro → TSX虚拟文件与源码映射src/language.ts与src/astro2tsx.ts负责最核心的语法桥接。AstroVirtualCode类把.astro文件声明为 Volar 虚拟代码并在构造时调用astro2tsx将文件内容交给astrojs/compiler的convertToTSX得到一份.tsx子虚拟代码作为嵌入式代码src/language.ts。值得注意的是几个与直觉不同的细节转换时显式传入includeScripts: false, includeStyles: false。注释解释称编译器默认会把script包裹成{() { ... }}其中的import声明在语法上是非法的会污染虚拟文件生成结果随后通过jridgewell/sourcemap-codec解码 source map并将映射逐段合并成可用的CodeMapping验证/补全/语义/导航/结构五个维度开启format维度关闭转换失败时不会抛出异常而是返回空代码与一条携带 severity 的诊断保证插件不会因单个语法错误文件而整体崩溃——这正是 1.0.9better handle when the Astro compiler fails to parse a file在源码层的落点patchTSX还会把编译产物中的__AstroComponent_占位符替换为基于文件名的合法标识符例如动态路由文件[id].astro会被映射为_id_形式确保类型与导航可用。内容集合智能感知yaml2ts 与 frontmatter 语言插件1.10.0 引入的 Content Collection Intellisense 由src/frontmatter.ts承载。它以astrojs/yaml2ts为工具为.md/.mdx/.mdoc分别映射为markdown/mdx/markdoc语言标识创建FrontmatterHolder虚拟代码先按astro sync生成的collections.json反查某个文件所属的集合再把 frontmatter 区域内的 YAML 交给yaml2ts转成 TS 虚拟代码从而让 frontmatter 字段具备基于集合 schema 的类型提示、错误检查与自动补全src/frontmatter.ts。这也解释了 CHANGELOG 中的两条细节1.10.3 修复schema 更新后内容未正确重载集合配置需要随 sync 产物同步刷新1.10.2 修复 Markdoc 文件的智能感知markdoc语言标识在当时未被正确识别。package.json 中astrojs/yaml2ts与主包版本绑定同步发布的记录同样印证了两者之间的强耦合。代理语言服务createProxyLanguageService来自volar/typescript提供了把补全、跳转等方法按需代理 覆写的机制。test/units/proxy-language-service.test.mts 用最小化用例验证了后续插件赋值的语言服务方法优先生效这正是插件能够把.astro/.md补全能力安全挂载到原生 TS 语言服务上的运行时基础。值得关注的兼容性与边界说明结合 CHANGELOG 与 package.json 的 devDependencies整理几条工程上重要的边界TypeScript 支持面devDependencies 中typescript: ^6.0.3历史上 1.3.1 起支持 TS 5.31.10.4 对 TS 5.6 有专门的性能调优1.10.9 起内部切换至 TS v6对用户透明。如果项目中锁定了较老的 TS 版本建议按具体版本对照 CHANGELOG 取舍Volar 版本策略1.10.1 起稳定在 Volar 2.4.x仓库根目录还保留着针对volar/typescript2.4.28的补丁见根目录 patches/volar__typescript2.4.28.patch说明核心依赖的版本钉得很死非必要不要自行升级与 VS Code 扩展的关系语言工具仓库内另含 language-server 与 vscode 子包。ts-plugin 与语言服务器的能力存在重叠但架构互补——语言服务器服务整文件诊断与更丰富的编辑器能力ts-plugin 主要驻留于 tsserver 进程两者共享同一套 Astro 安装定位与类型注入策略源码注释多处标注mirrors the language server。结语一条脚手架已就位、能力持续外扩的演进路径回顾 astrojs/ts-plugin 的 CHANGELOG 与源码可以提炼出它清晰的三阶段演进先以编译器补丁解决.astro导入与跨文件导航的可用性问题再以 Volar 架构统一语言服务与插件两端的底座最后围绕内容集合智能感知与 monorepo 精确性做精细化打磨。对使用者而言它的配置成本极低一行插件注册却能在 TS/JS 文件中解锁.astro的导入解析、符号重命名、引用查找、路径补全与内容集合 frontmatter 类型提示对想深入了解 Astro 工具链的开发者而言src/astro-types.ts、src/language.ts 与 test/units/astro-types.test.mts 是三条互为印证、值得精读的实现与验证入口。【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
astrojs/ts-plugin 演进全解析Astro 语言服务背后的 TypeScript 插件【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astroastrojs/ts-plugin 是 Astro 官方提供的一款 TypeScript 插件让普通.ts文件也能获得.astro、.md、.mdx、.mdoc等文件的智能感知能力。本文以该插件在仓库中的 CHANGELOG.md 为主体脉络结合其源码实现与测试用例系统梳理它的功能边界、架构演进与典型配置方法。Astro 内容型网站的工程实践中TypeScript 文件与.astro模板文件常常相互引用例如在.ts中封装工具函数、再由模板消费。传统 TypeScript 语言服务不理解.astro语法导致跨文件跳转、重命名、引用查找全部失效。astrojs/ts-plugin 正是为了解决这一断层而生它把.astro代码转换成 TypeScript 可理解的虚拟文件并在必要时把 Astro 的环境类型注入程序使Astro.locals、Astro.self、内容集合 schema 等类型链条在编辑器与类型检查器中保持完整。插件定位与语言服务器分工但能力互补Astro 官方工具链分为两层astrojs/language-serverVolar 语言服务器支撑 VS Code 扩展与astrojs/ts-pluginTypeScript 服务端插件。README 明确说明使用官方 Astro VS Code 扩展时插件会被自动安装并配置见 ts-plugin/README.md。当你在纯 TypeScript 编辑器环境不依赖语言服务器或通过tsserver做跨文件分析时插件的价值就凸显出来——它负责的是 TS 文件看到 Astro 文件这一侧的能力。从 package.json 的依赖清单可以反推其内部结构astrojs/compiler将.astro源码转换为 TSX 的核心编译器astrojs/yaml2ts将 Markdown/MDX 等 frontmatter 的 YAML 内容转换为 TS 虚拟代码volar/language-core与volar/typescriptVolar 框架的虚拟代码与语言服务代理底座volar/typescriptcreateLanguageServicePlugin与createProxyLanguageService的出处vscode-languageserver-textdocument虚拟文本文档的构建工具。安装与最小配置通过createLanguageServicePlugin工厂导出的插件安装方式非常简单。在任意.ts/.js项目中执行npm install --save-dev astrojs/ts-plugin然后在项目的tsconfig.json中注册{ compilerOptions: { plugins: [ { name: astrojs/ts-plugin } ] } }配置完成后TypeScript 语言服务会在处理项目时加载该插件。它本身不含任何用户可调的选项参数属于安装即生效的插件所有智能感知逻辑均由插件内部自动完成。版本演进主线从编译器补丁到 Volar 一体化CHANGELOG.md完整记录了插件从预发布0.x到 1.x 正式版的历史。这条时间线本质上映射了 Astro 官方对编辑器工具化的两轮重构先是围绕astrojs/compiler做定点修补随后在 1.1.0 全面迁往 Volar 架构此后所有功能都以语言插件 虚拟代码的模式叠加。0.x能力奠基期0.2.0移除插件内置的astro.d.ts改为优先使用 Astro 包自带的环境类型避免双重声明冲突0.4.0完整支持在 JS/TS 中导入.astro的能力——包含 Astro 文件内的引用查找、.astro/.md/.mdx路径补全以及若干跳转定义/实现失效的修复0.4.2为.astro文件内的符号提供重命名支持0.4.3针对astro:content导入报错在错误信息中补充如何生成内容集合类型的指引。这一阶段确立了插件最核心的产品承诺TypeScript plugin adding support for .astro imports in .ts files同时支持跨.ts与.astro文件的符号重命名与引用查找。1.xVolar 化与能力跃迁1.1.0插件整体切换到 Volar 架构。CHANGELOG 中特别类比Volar 之于编辑器工具正如 Vite 之于构建——它成为插件稳定性、性能以及后续功能扩展的统一底座1.3.0新增Astro.self智能感知并开始为getStaticPaths自动推断props类型1.3.1在 1.3.0 基础上自动把getStaticPaths推断出的联合类型互相拍平flatten使存在分歧的props在解构前无需手动判别同时宣告支持 TypeScript 5.31.4.0重构 Astro 的 JSX 类型定义修复其他 JSX 框架用户的若干类型检查问题1.5.0升级至 Volar 2.0。由于属于底层架构更替CHANGELOG 明确请求用户上报回归问题1.8.0 / 1.9.0持续升级语言服务器所依赖的 Volar 版本其中 1.9.0 修复了script标签内智能感知的一系列问题1.10.0新增内容集合智能感知Content Collection Intellisense随附astrojs/yaml2ts升级至 0.2.0。这是插件此后几次大版本更新的主题词。将 1.10.0 与 1.10.11 之间的发布串联起来可以看到一条针对内容集合智能感知与 monorepo 场景持续打磨的完整迭代链。这里摘取几个高信息量的 Patch版本类型核心变更1.9.0 / 1.8.0 / 1.7.0 / 1.6.1 / 1.6.0 / 1.5.0Minor逐级升级 Volar 至 2.0修复缓存、TSX 解析、缺失 Prettier 导致的崩溃等1.10.0Minor新增 Content Collection Intellisense1.10.1Patch升级至 Volar 2.4.0 稳定版1.10.2Patch修复 Markdocmarkdoclanguage identifier内内容智能感知失效1.10.3Patch修复内容 schema 更新后未能正确重载的若干场景1.10.4Patch改善 TS 5.6 下的性能仍低于 5.5但已可正常使用1.10.5Patch更新内部 Volar 版本兼容更新版本 TypeScript1.10.9Patchtypescript依赖升级至 v6用户无需任何改动1.10.10Patch修复.ts中经Astro.locals链式访问的、位于.astro文件内的引用缺失问题1.10.11Patch修复 Astro 环境类型泄漏到无关 TS 项目的问题从源码看实现原理插件虽然以Patch节奏发布但其内部机制并不浅。以下机制共同构成了让 TS 理解 Astro的完整链路。入口按需组装语言插件在 src/index.ts 中插件通过 Volar 的createLanguageServicePlugin注册初始化逻辑分为三步调用isAstroProject判断当前目录是否属于 Astro 项目若成立则调用addAstroTypes注入环境类型尝试读取./.astro/collections/collections.jsonastro sync生成的产物拿到内容集合 schema 信息依据 schema 是否存在决定是否追加frontmatter 语言插件负责内容集合的 frontmatter 智能感知。这解释了 CHANGELOG 中 1.10.10 与 1.10.11 两个 Patch 的源码由来注入发生在项目初始化时因此判断是否 Astro 项目与注入哪些类型文件必须足够精确否则就会在 monorepo 场景引入副作用。环境类型注入与 monorepo 泄漏修复1.10.10 / 1.10.11src/astro-types.ts是 1.10.10 与 1.10.11 两次修复的主战场addAstroTypes会向上层目录逐级查找已安装的astro包将其中存在的env.d.ts与astro-jsx.d.ts两个文件追加进宿主getScriptFileNames()的返回结果。这是.ts文件中的 Go To References 能看到.astro内经Astro.locals触达的用法的关键——没有Astro全局声明Astro.locals.utils.toUpper()这类类型链无法解析引用自然丢失。实现同时用WeakSetts.LanguageServiceHost保证每个宿主只被装饰一次避免重复注入src/astro-types.ts。1.10.11 的泄漏问题则源于isAstroProject的判断标准。其逻辑是就近查找package.json若dependencies/devDependencies/peerDependencies中出现astro或在package.json同级目录下存在astro.config.*文件才判定为 Astro 项目。在 hoistednode_modules的 monorepo 中插件旧版可能从任意项目共享astro安装把env.d.ts/astro-jsx.d.ts注入到从未请求过它们的项目从而把types/node一并拉入。修复后只有真正依赖astro或拥有astro.config.*的项目才会被注入。对应的 test/units/astro-types.test.mts 直接用临时目录构造了三类 monorepo 项目依赖 Astro 的 docs、只依赖 React 的 frontend、仅含astro.config.mjs的 standalone逐一断言isAstroProject的判定结果同时又构造了Astro.locals.utils.toUpper()的 fixture验证注入前引用缺失、注入后引用可查——这是理解两次 Patch 行为最直观的可运行文档。.astro → TSX虚拟文件与源码映射src/language.ts与src/astro2tsx.ts负责最核心的语法桥接。AstroVirtualCode类把.astro文件声明为 Volar 虚拟代码并在构造时调用astro2tsx将文件内容交给astrojs/compiler的convertToTSX得到一份.tsx子虚拟代码作为嵌入式代码src/language.ts。值得注意的是几个与直觉不同的细节转换时显式传入includeScripts: false, includeStyles: false。注释解释称编译器默认会把script包裹成{() { ... }}其中的import声明在语法上是非法的会污染虚拟文件生成结果随后通过jridgewell/sourcemap-codec解码 source map并将映射逐段合并成可用的CodeMapping验证/补全/语义/导航/结构五个维度开启format维度关闭转换失败时不会抛出异常而是返回空代码与一条携带 severity 的诊断保证插件不会因单个语法错误文件而整体崩溃——这正是 1.0.9better handle when the Astro compiler fails to parse a file在源码层的落点patchTSX还会把编译产物中的__AstroComponent_占位符替换为基于文件名的合法标识符例如动态路由文件[id].astro会被映射为_id_形式确保类型与导航可用。内容集合智能感知yaml2ts 与 frontmatter 语言插件1.10.0 引入的 Content Collection Intellisense 由src/frontmatter.ts承载。它以astrojs/yaml2ts为工具为.md/.mdx/.mdoc分别映射为markdown/mdx/markdoc语言标识创建FrontmatterHolder虚拟代码先按astro sync生成的collections.json反查某个文件所属的集合再把 frontmatter 区域内的 YAML 交给yaml2ts转成 TS 虚拟代码从而让 frontmatter 字段具备基于集合 schema 的类型提示、错误检查与自动补全src/frontmatter.ts。这也解释了 CHANGELOG 中的两条细节1.10.3 修复schema 更新后内容未正确重载集合配置需要随 sync 产物同步刷新1.10.2 修复 Markdoc 文件的智能感知markdoc语言标识在当时未被正确识别。package.json 中astrojs/yaml2ts与主包版本绑定同步发布的记录同样印证了两者之间的强耦合。代理语言服务createProxyLanguageService来自volar/typescript提供了把补全、跳转等方法按需代理 覆写的机制。test/units/proxy-language-service.test.mts 用最小化用例验证了后续插件赋值的语言服务方法优先生效这正是插件能够把.astro/.md补全能力安全挂载到原生 TS 语言服务上的运行时基础。值得关注的兼容性与边界说明结合 CHANGELOG 与 package.json 的 devDependencies整理几条工程上重要的边界TypeScript 支持面devDependencies 中typescript: ^6.0.3历史上 1.3.1 起支持 TS 5.31.10.4 对 TS 5.6 有专门的性能调优1.10.9 起内部切换至 TS v6对用户透明。如果项目中锁定了较老的 TS 版本建议按具体版本对照 CHANGELOG 取舍Volar 版本策略1.10.1 起稳定在 Volar 2.4.x仓库根目录还保留着针对volar/typescript2.4.28的补丁见根目录 patches/volar__typescript2.4.28.patch说明核心依赖的版本钉得很死非必要不要自行升级与 VS Code 扩展的关系语言工具仓库内另含 language-server 与 vscode 子包。ts-plugin 与语言服务器的能力存在重叠但架构互补——语言服务器服务整文件诊断与更丰富的编辑器能力ts-plugin 主要驻留于 tsserver 进程两者共享同一套 Astro 安装定位与类型注入策略源码注释多处标注mirrors the language server。结语一条脚手架已就位、能力持续外扩的演进路径回顾 astrojs/ts-plugin 的 CHANGELOG 与源码可以提炼出它清晰的三阶段演进先以编译器补丁解决.astro导入与跨文件导航的可用性问题再以 Volar 架构统一语言服务与插件两端的底座最后围绕内容集合智能感知与 monorepo 精确性做精细化打磨。对使用者而言它的配置成本极低一行插件注册却能在 TS/JS 文件中解锁.astro的导入解析、符号重命名、引用查找、路径补全与内容集合 frontmatter 类型提示对想深入了解 Astro 工具链的开发者而言src/astro-types.ts、src/language.ts 与 test/units/astro-types.test.mts 是三条互为印证、值得精读的实现与验证入口。【免费下载链接】astroThe web framework for content-driven websites. ⭐️ Star to support our work!项目地址: https://gitcode.com/GitHub_Trending/as/astro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
