前端SSG:静态站点生成的艺术

前端SSG:静态站点生成的艺术

毒舌时刻

前端SSG?这不是给博客用的吗?

"我的应用需要动态内容,SSG不适合"——结果首屏加载慢,SEO差,
"SSG就是静态HTML,太简单了"——结果构建时间长,数据更新困难,
"我用SSR就够了"——结果服务器压力大,响应慢。

醒醒吧,SSG不是简单的静态HTML,而是一种现代化的前端架构!

为什么你需要这个?

  • 性能优异:静态文件加载快,无需服务器渲染
  • SEO友好:所有内容都是静态的,搜索引擎容易收录
  • 部署简单:可以部署到任何静态文件服务器
  • 安全性高:没有服务器端代码,减少攻击面

反面教材

// 反面教材:纯静态HTML <!DOCTYPE html> <html> <head> <title>我的博客</title> </head> <body> <h1>我的博客</h1> <div> <h2>第一篇文章</h2> <p>文章内容...</p> </div> <div> <h2>第二篇文章</h2> <p>文章内容...</p> </div> <!-- 手动更新内容,非常麻烦 --> </body> </html> 

正确的做法

// 正确的做法:使用Next.js SSG // pages/index.js export async function getStaticProps() { // 在构建时获取数据 const res = await fetch('https://api.example.com/posts'); const posts = await res.json(); return { props: { posts }, // 重新验证时间(秒) revalidate: 10 }; } function Home({ posts }) { return ( <div> <h1>我的博客</h1> <div className="posts"> {posts.map((post) => ( <div key={post.id} className="post"> <h2>{post.title}</h2> <p>{post.content}</p> </div> ))} </div> </div> ); } export default Home; // 正确的做法:使用Astro // src/pages/index.astro --- // 前端组件 import Header from '../components/Header.astro'; import Footer from '../components/Footer.astro'; // 在构建时获取数据 const res = await fetch('https://api.example.com/posts'); const posts = await res.json(); --- <html lang="zh-CN"> <head> <title>我的博客</title> </head> <body> <Header /> <main> <h1>我的博客</h1> <div> {posts.map((post) => ( <div key={post.id}> <h2>{post.title}</h2> <p>{post.content}</p> </div> ))} </div> </main> <Footer /> </body> </html> // 正确的做法:使用Gatsby // gatsby-node.js exports.createPages = async ({ graphql, actions }) => { const { createPage } = actions; // 查询数据 const result = await graphql(` query { allMarkdownRemark { edges { node { frontmatter { path } } } } } `); // 创建页面 result.data.allMarkdownRemark.edges.forEach(({ node }) => { createPage({ path: node.frontmatter.path, component: path.resolve('./src/templates/blog-post.js'), context: { // 传递数据到模板 } }); }); }; // src/templates/blog-post.js import React from 'react'; import { graphql } from 'gatsby'; export const query = graphql` query($path: String!) { markdownRemark(frontmatter: { path: { eq: $path } }) { frontmatter { title date } html } } `; const BlogPost = ({ data }) => { return ( <div> <h1>{data.markdownRemark.frontmatter.title}</h1> <p>{data.markdownRemark.frontmatter.date}</p> <div dangerouslySetInnerHTML={{ __html: data.markdownRemark.html }} /> </div> ); }; export default BlogPost; 

毒舌点评

看看,这才叫前端SSG!不是简单的静态HTML,而是使用Next.js、Astro、Gatsby等现代化框架,在构建时生成静态页面。

记住,SSG不是只能用于博客,它可以用于任何需要高性能、SEO友好的网站。通过增量静态再生(ISR)等技术,它还可以支持动态内容。

所以,别再觉得SSG简单了,它是现代前端开发的重要选择!

总结

  • Next.js SSG:支持静态生成和增量静态再生
  • Astro:专注于静态站点生成,支持多种框架
  • Gatsby:基于React的静态站点生成器,生态丰富
  • 构建时数据获取:在构建过程中获取数据,生成静态页面
  • 增量静态再生:定期重新生成页面,保持内容新鲜
  • 客户端交互:通过JavaScript添加动态交互
  • 部署灵活:可以部署到Vercel、Netlify等平台
  • 性能优化:自动代码分割、图片优化等

SSG,让你的网站既快又友好!

Read more

【昇腾】单张96G Atlas 300I Duo推理卡MindIE+WebUI方式跑32B大语言模型_20250818

【昇腾】单张96G Atlas 300I Duo推理卡MindIE+WebUI方式跑32B大语言模型_20250818

一、Atlas 300I Duo推理卡相关安装步骤 由于显存的瓶颈,48G的Atlas 300I Duo推理卡是没办法跑得起来DeepSeek-R1-Distill-Qwen-32B大语言模型的,这里换了一张96G版本的Atlas 300I Duo推理卡来跑,32B大语言模组除了对显存有要求,对服务器本身的内存条也有要求,在加载的过程中需要较大的内存,这里服务器的内存条内存为128GB 1.1 服务器系统与内核说明 服务器系统版本内核版本内存条内存S5000CKylin V104.19.90-89.11.v2401.ky10.aarch64128GB P.S.服务器安装好系统后先不要执行yum update -y更新,否则内核版本会从4.19.90-89.11升级到4.19.90-89.21,Atlas 300I Duo推理卡的driver包会安装失败 1.2 系统环境说明 本服务器IP地址:192.168.2.71 登录用户:

Spring Boot 中基于 WebClient 的 SSE 流式接口实战

—— 从 Feign 到 WebClient 的一次真实踩坑记录 一、背景:为什么我要做 SSE? 在最近的一个项目中,我负责接入一个 AI 问答服务。 一开始的接口形态非常常规: @PostMapping("/health_manager") public RespBean<HealthManagerQueryDataVO> sendQuery(...) 客户端发请求,服务端等 AI 全部生成完内容,再一次性返回。 问题很快就暴露了: * AI 返回慢(10 秒甚至更久) * 用户页面“卡死”,体验极差 * 其实 AI 是“边生成边返回”的,但我们完全浪费了这个能力 于是,目标就很明确了: 把原有同步接口,改造成支持 SSE(Server-Sent

Web 前端基础知识点汇总

Web 前端基础知识点汇总

一、HTML 基础 1.1 浏览器内核 浏览器内核核心包含渲染引擎(解析 HTML/CSS,渲染页面)和JS 引擎(解析执行 JavaScript),不同浏览器内核差异如下: 浏览器内核备注IETrident适配 IE、早期 EdgeFirefoxGecko近年市场份额下降,存在打开速度慢、升级频繁问题SafariWebKit常被误称为 Chrome 内核(Chrome 现已改用 Blink)ChromeChromium/BlinkBlink 是 WebKit 分支,多数国产浏览器最新版基于 Blink 二次开发OperaPresto/Blink早期用 Presto,现跟随 Chrome 使用 BlinkEdgeEdgeHTML/Blink新版 Edge 已切换为 Blink 内核 1.2 Web 标准(

【n8n入门教程08】n8n 触发节点完全指南:定时器、Webhook 和手动触发

n8n工作流分享:商业级别的5个实用自动化工作流分享,诚意满满 n8n 触发节点完全指南:定时器、Webhook 和手动触发 在 n8n 自动化平台中,触发节点是工作流的起点,决定了整个流程的启动方式。无论是定时任务、外部事件还是手动测试,合理选择和配置触发节点,是实现高效自动化的基础。今天就来详细讲讲 n8n 的三类主流触发节点,帮你灵活应对各种业务场景。 手动触发节点(Manual Trigger) Manual Trigger 节点主要用于开发和调试阶段。把它放在工作流起点后,可以通过编辑器的 “Execute Workflow” 按钮手动启动流程,实时观察结果。 这个节点不会自动运行,也无法被外部事件触发,只有在你手动执行时才会生效。特别适合测试用途,你可以通过它手动运行整个流程,验证逻辑和数据流是否符合预期。 使用场景: * 开发调试新工作流 * 测试工作流的各个节点 * 验证数据流转是否正确 注意事项: * 一个工作流只能有一个 Manual Trigger 节点 * 仅在开发调试时使用,生产环境应该用其他触发器