尧图网站建设 
1. 项目概述为什么我要重建我的GitHub Pages博客几年前我随手用Jekyll搭了个博客扔在GitHub Pages上想着能写点东西就行。那时候觉得免费、省心、能绑定域名还要啥自行车确实GitHub Pages这套组合拳——静态站点生成器加托管——对于技术分享、个人记录来说初期简直完美。但随着时间推移问题一个个冒出来了访问速度时快时慢尤其是在某些网络环境下主题老旧想改个样式发现当初选的主题文档不全牵一发而动全身更别提那些零散的插件和自定义配置连我自己都快忘了当初是怎么拼凑起来的。每次想写新文章都得先跟这个陈旧的系统“搏斗”一番写作的热情被磨掉大半。所以“重建”这个念头不是一时兴起而是一次彻底的“系统重装”。这次的目标很明确在保留GitHub Pages核心优势免费、与Git工作流无缝集成的前提下打造一个更快、更稳、更易维护的现代化静态博客。重建不是推倒重来那么简单它涉及到生成器选型、部署优化、CDN加速、评论系统迁移等一系列环节。简单说我想从一个“勉强能用”的状态升级到一个“用得顺手甚至有点享受”的状态。如果你也在用GitHub Pages但总觉得哪里差了点意思或者正准备从零开始搭建那么我踩过的坑、总结的方案或许能帮你省下不少折腾的时间。2. 核心需求与方案选型不止于“换个主题”重建的第一步是明确需求。我列了个清单问自己到底想要什么极致的访问速度与稳定性全球访问都应该是快速的且具备抗DDoS等基础安全能力。高度的可维护性与可定制性主题结构清晰文档齐全方便后续自定义样式和功能。平滑的内容迁移旧博客的文章Markdown文件必须能无损迁移URL结构最好也能保持这对SEO很重要。完整的博客生态评论、搜索、分析等周边功能需要易于集成。未来的扩展性能方便地集成自动化工作流比如自动部署、资源优化等。基于这些需求我评估了几个主流方案2.1 静态站点生成器SSG选型为什么最终还是Jekyll市面上SSG很多Hugo、Hexo、Next.js、Gatsby都很火。Hugo以编译速度著称Hexo生态丰富尤其对中文用户Next.js则代表了前沿的React框架。我为什么还是选了“老牌”的Jekyll原生集成与零配置GitHub Pages对Jekyll的支持是“亲生儿子”级别的。你只需要把符合Jekyll目录结构的代码推送到gh-pages分支或主分支的特定目录GitHub会自动识别、构建并部署。这意味着你完全不需要在本地或云端配置构建环境也无需关心依赖安装。对于追求简洁和“开箱即用”的场景这是巨大的优势。其他生成器大多需要配置GitHub Actions来实现自动构建多了一个环节就多了一份出错的概率。内容迁移成本最低我的旧博客就是Jekyll的文章都是Markdown文件Front Matter文章头部的YAML配置格式通用。迁移到另一个Jekyll主题几乎只需要复制粘贴文章文件并微调一下Front Matter中的标签分类即可。如果换用其他生成器虽然也有迁移工具但难免会遇到格式兼容性问题需要手动调整工作量不可控。足够的主题与插件生态Jekyll社区历史悠久有大量成熟、高质量的主题。更重要的是许多主题作者都考虑到了GitHub Pages的兼容性会避免使用需要额外构建步骤的插件。对于我的需求博客它的功能完全够用。当然Jekyll的缺点也很明显Ruby环境在非Mac/Linux系统上可能有点麻烦但GitHub Pages托管帮你省了这一步编译速度对于超大型站点可能较慢。但对于一个个人博客来说这些都不是核心痛点。选型的核心原则是用最少的持续维护成本满足核心需求。JekyllGitHub Pages的组合在“省心”这一点上目前依然很难被超越。2.2 主题选择从“功能堆砌”到“简洁核心”以前我喜欢找功能丰富的主题评论、相册、音乐播放器啥都有。这次我反其道而行之选择了一个结构极其清晰、代码注释完整、专注于写作和阅读体验的极简主题。原因有三专注博客的核心是内容。花里胡哨的功能会分散读者和自己的注意力。可维护简单的主题意味着更少的代码更清晰的逻辑。当我想自定义某个部分时我能很快找到对应的文件并理解其作用而不是在一堆复杂的模板和脚本中迷失。性能更少的JavaScript和CSS意味着更快的加载速度。很多功能可以通过外部服务如评论用Disqus或Gitalk搜索用Algolia来集成保持核心站点的轻量。我最终选择了一个基于minima主题深度定制并完全重写的开源主题它保留了Jekyll的标准目录结构但样式现代且所有布局文件_layouts/和包含文件_includes/都写得非常易懂。2.3 加速与安全方案引入Cloudflare CDN这是本次重建提升体验最关键的一步。GitHub Pages的服务器主要在美国国内访问速度不稳定是众所周知的痛点。直接解决方案就是加一层CDN内容分发网络。为什么是Cloudflare首先它免费套餐的功能对于个人博客来说已经非常强大全球CDN、DDoS防护、SSL证书支持灵活SSL和完全SSL、防火墙规则、缓存优化等。其次它的配置界面相对友好与域名服务的集成修改NS记录或CNAME是标准操作。核心价值加速用户访问你的博客blog.yourdomain.com时请求会先到达离他最近的Cloudflare节点。如果该节点有缓存直接返回速度极快如果没有Cloudflare会回源到你的GitHub Pages地址yourusername.github.io获取内容并缓存。对于静态资源图片、CSS、JS缓存效果显著。隐藏源站你的真实服务器GitHub PagesIP对公众是隐藏的由Cloudflare作为代理这在一定程度上提升了安全性。HTTPS无忧Cloudflare提供免费的SSL证书你只需要在控制台一键开启“SSL/TLS”的“完全”模式它就会帮你处理浏览器到Cloudflare、以及Cloudflare到GitHub Pages之间的加密无需自己在服务器上管理证书。注意使用Cloudflare CDN后你的访客和GitHub看到的访问IP都将是Cloudflare节点的IP这会导致GitHub Pages内置的访问日志统计失效也会影响一些基于IP的功能如果你有的话。通常这对于博客来说是可以接受的统计可以交给Google Analytics或Cloudflare自家的分析。3. 详细实施步骤从零到一的完整记录3.1 本地环境准备与主题初始化虽然GitHub Pages会自动构建但在本地预览和调试是必不可少的。你需要一个本地Jekyll环境。安装Ruby与Jekyll以macOS为例其他系统请参考官方文档# 使用Homebrew安装Ruby如果系统Ruby版本旧 brew install ruby # 将新安装的Ruby路径添加到shell配置如.zshrc echo export PATH/usr/local/opt/ruby/bin:$PATH ~/.zshrc source ~/.zshrc # 安装Jekyll和Bundler gem install --user-install bundler jekyll安装后运行jekyll -v和bundle -v确认安装成功。创建新博客项目jekyll new myblog --skip-bundle cd myblog--skip-bundle参数是为了先不安装依赖因为我们可能要换主题。替换主题 删除自动生成的minima主题相关文件主要是_layouts,_includes,_sass目录和index.md等然后将你选中的新主题文件全部复制过来。或者更推荐的方式是直接Fork或Clone你心仪的主题仓库以此作为起点。这样能保证目录结构完全正确。安装依赖并本地运行bundle install bundle exec jekyll serve访问http://localhost:4000你应该能看到新主题的预览效果。3.2 内容迁移与配置调整这是最需要耐心的一步。文章迁移将旧博客_posts目录下的所有.md文件复制到新项目的_posts目录。检查每篇文章的Front Matter确保关键字段如title、date、layout、categories、tags与新主题的要求一致。通常title和date是通用的layout可能需要根据新主题的布局文件名称修改如从post改为default。静态资源迁移将旧博客的图片、附件等资源通常在assets、images或uploads目录复制到新项目的对应目录。建议借此机会整理资源删除无用文件并使用压缩工具优化图片体积。配置文件_config.yml这是Jekyll的核心。你需要仔细配置title,description,url,baseurl站点基本信息。theme如果你用的主题是Gem-based这里填主题Gem名如果是直接复制文件的则删除或注释掉这一行。plugins列出需要的插件如jekyll-feedRSS、jekyll-sitemap站点地图。确保它们在Gemfile中也有定义。defaults为特定路径的文件设置默认Front Matter非常有用。例如可以为所有_posts下的文件默认设置layout: post。主题特定的配置如社交链接、评论设置Disqus shortname、Google Analytics ID等参考主题文档填写。测试与验证本地运行bundle exec jekyll serve逐一点开每篇文章检查格式是否正确、图片是否显示、链接是否有效。特别检查分类页和标签页是否正常工作。3.3 部署到GitHub Pages并绑定自定义域名创建GitHub仓库在GitHub上创建一个名为你的用户名.github.io的公开仓库。这是使用GitHub Pages个人站点的最简单方式。推送代码git init git add . git commit -m Initial commit with new blog git branch -M main git remote add origin https://github.com/你的用户名/你的用户名.github.io.git git push -u origin main等待构建推送后GitHub Actions会自动开始构建对于Jekyll项目。你可以在仓库的“Actions”标签页查看构建状态。成功后访问https://你的用户名.github.io就能看到新博客。绑定自定义域名在域名注册商处为你的域名例如blog.yourdomain.com添加一条CNAME记录指向你的用户名.github.io。在你的博客项目根目录下创建一个名为CNAME的文件无后缀里面只写一行你的域名blog.yourdomain.com。将CNAME文件提交并推送到GitHub仓库。在GitHub仓库的 Settings - Pages 页面Custom domain部分填入你的域名并保存。GitHub会尝试验证并为你自动配置一个用于验证的A记录你可以选择使用它也可以稍后在DNS处自己配置。建议先使用GitHub提供的验证方式成功后再进行下一步的CDN配置。3.4 配置Cloudflare CDN加速这是将访问体验提升一个档次的关键。将域名接入Cloudflare在Cloudflare官网注册并添加你的网站例如yourdomain.com。Cloudflare会扫描你现有的DNS记录并给出两个Cloudflare的Nameserver地址如lara.ns.cloudflare.com。回到你的域名注册商控制台将域名的Nameserver修改为Cloudflare提供的那两个。这个过程称为“更改NS记录”生效需要几小时到48小时。配置DNS记录等待NS生效后在Cloudflare的DNS管理页面你需要添加一条记录来指向你的博客。重要这里有两种方法方法A推荐更清晰为博客子域名单独设置。类型CNAME名称blog目标你的用户名.github.io代理状态已代理橙色云朵。方法B根域名如果你想用根域名yourdomain.com访问博客GitHub Pages要求配置A记录指向其IP。你需要添加多条A记录名称目标分别指向GitHub Pages的四个IP185.199.108.153,185.199.109.153,185.199.110.153,185.199.111.153代理状态同样开启。确保之前在GitHub仓库中创建的CNAME文件内容与你这里设置的记录一致例如blog.yourdomain.com。配置SSL/TLS在Cloudflare控制台的SSL/TLS选项卡下将加密模式设置为“完全严格”。这个模式要求从Cloudflare到你的源站GitHub Pages的连接也是加密的。由于GitHub Pages本身就支持HTTPS并提供有效证书所以这个模式是安全的。“边缘证书”部分确保“始终使用HTTPS”选项是开启的。这会将所有HTTP请求重定向到HTTPS。优化缓存与速度速度选项卡可以开启“Auto Minify”自动压缩HTML、CSS、JS代码。缓存选项卡这是重点。配置“缓存级别”为“标准”。在“缓存规则”中可以创建一条规则来缓存所有静态资源。例如创建一个页面规则如果URL匹配*blog.yourdomain.com/*.jpg或*.css或*.js则设置“缓存级别”为“缓存所有内容”并设置一个较长的“边缘缓存TTL”如一个月。对于博客文章页面HTML由于内容会更新缓存时间可以设短一些或者使用“标准”缓存级别并依靠Cloudflare的“浏览器缓存TTL”设置。验证等待DNS完全生效后访问你的自定义域名如https://blog.yourdomain.com。打开浏览器开发者工具的“网络”选项卡查看请求的响应头。你应该能看到CF-Cache-Status: HIT缓存命中或MISS未命中但下次访问可能就是HIT了以及Server: cloudflare等字样这表示流量已经成功经过Cloudflare加速。4. 周边功能集成与优化博客的核心是内容但一些周边功能能极大提升互动性和可管理性。4.1 评论系统从Disqus到更轻量的选择过去Disqus是标配但它臃肿、加载慢、有广告。现在有更优选择Giscus我目前使用的方案。它利用GitHub Discussions作为评论存储后端。访客使用GitHub账号登录即可评论。优点是完全免费、无广告、与开发者社区无缝集成评论内容以Issues的形式保存在你自己的仓库里数据自主。配置步骤确保你的博客仓库已启用Discussions功能Settings - General - Features - Discussions。安装Giscus App到你的仓库授权。访问 giscus.app 根据向导配置选择仓库、映射方式等生成一段脚本代码。将这段脚本代码嵌入到你的Jekyll主题的评论布局文件通常是_includes/comments.html中。Utterances与Giscus类似但使用GitHub Issues而非Discussions。原理和配置方式相近也是一个轻量级的好选择。Twikoo一个基于云函数的评论系统支持多种登录方式界面美观。需要自行部署一个后端云函数如Vercel、腾讯云SCF稍微复杂一点但可控性更强。实操心得对于技术博客Giscus非常合适因为读者大概率有GitHub账号。它的加载速度比Disqus快得多且没有隐私顾虑。唯一的“门槛”是访客需要有GitHub账号。4.2 站内搜索让内容更容易被找到静态站点无法进行服务端搜索需要借助前端JavaScript或第三方服务。Simple Jekyll Search一个纯客户端的JavaScript搜索库。它会在构建时生成一个包含所有文章标题、内容和URL的JSON文件search.json。访客搜索时JS直接在这个JSON文件里进行匹配。优点是完全免费、无需外部依赖、隐私友好。缺点是文章数量巨大时比如上千篇JSON文件会比较大影响初始加载且搜索算法相对简单。集成方法在_config.yml中配置生成search.json。然后在主题中引入其JS文件并添加一个搜索输入框和结果展示容器。很多Jekyll主题已经内置了此功能。Algolia专业的搜索即服务。它能提供更快、更相关、支持拼音纠错等高级功能的搜索体验。它提供免费的社区套餐每月一定额度的搜索次数和记录数对个人博客通常够用。但需要将你的站点内容通过API或自动化脚本推送到Algolia配置步骤稍多。我选择了Simple Jekyll Search因为它足够简单且与静态博客“自给自足”的理念更契合。对于几百篇文章的博客其性能完全可接受。4.3 自动化与持续集成让更新更省心虽然GitHub Pages已经自动化了构建部署但我们还可以做得更好自动提交Sitemap到搜索引擎每次博客更新都希望Google、Bing能尽快收录。可以在_config.yml中启用jekyll-sitemap插件自动生成sitemap.xml。然后可以利用GitHub Actions在每次推送代码后自动向Google Search Console等平台提交这个sitemap。这需要你配置一个包含相应API调用的Action工作流文件.github/workflows/submit-sitemap.yml。资源优化可以在本地构建流程中集成图片压缩工具如imagemin或者使用GitHub Actions在构建前自动压缩图片。同样也可以集成CSS/JS的压缩和合并工具。链接检查定期运行死链检查确保博客没有失效的链接。可以设置一个每周运行的GitHub Action使用lychee或linkchecker这样的工具扫描你的站点并将报告发送到你的邮箱或生成一个Issue。这些自动化脚本一开始可能觉得麻烦但一旦设置好就是一劳永逸的“数字管家”能帮你维护博客的健康状态。5. 常见问题与排查实录在重建和后续维护过程中我遇到了不少典型问题这里记录下排查思路。5.1 本地运行正常推送到GitHub后页面空白或样式错乱问题描述bundle exec jekyll serve本地预览一切完美但推送到GitHub Pages后访问网站发现只有纯文本没有CSS样式或者布局全乱。排查步骤检查_config.yml中的url和baseurl这是最常见的原因。url应设置为你的最终访问地址如https://blog.yourdomain.combaseurl如果你站点不在根路径则设置例如/blog否则就留空。本地运行时Jekyll可能会忽略这些设置或使用默认值但GitHub Pages构建时会严格使用这些值来生成资源链接。错误的baseurl会导致所有CSS/JS的链接路径错误。检查GitHub Pages构建日志在仓库的“Actions”标签页找到最新的Pages构建工作流点开查看详细日志。构建失败Build failed会直接导致站点无法更新。常见失败原因使用了GitHub Pages不支持的自定义插件白名单外的插件、Ruby版本不兼容、Gemfile中依赖冲突或语法错误。检查主题引用方式如果你使用的是Gem-based主题确保_config.yml中theme设置正确且Gemfile中包含该主题gem。如果你是把主题文件直接复制到项目里的确保_config.yml中没有theme这一项或者已被注释掉否则Jekyll会去寻找一个不存在的Gem。使用github-pagesGem在Gemfile中使用gem github-pages, group: :jekyll_plugins并运行bundle update github-pages。这个Gem包确保了本地环境与GitHub Pages服务器环境的一致性能最大程度避免“本地行线上不行”的问题。5.2 Cloudflare CDN配置后访问出现“重定向过多”错误问题描述配置Cloudflare并开启“始终使用HTTPS”后访问网站出现ERR_TOO_MANY_REDIRECTS错误。原因与解决这是SSL/TLS设置和源站配置冲突的典型表现。首先确认Cloudflare的SSL/TLS加密模式。强烈建议使用“完全严格”模式。如果使用“灵活”模式浏览器到Cloudflare是HTTPSCloudflare到GitHub Pages是HTTP而GitHub Pages又强制跳转HTTPS就可能形成循环重定向。其次检查你的GitHub Pages仓库设置。在Settings - Pages - Custom domain下确保“Enforce HTTPS”复选框是勾选的。这个选项告诉GitHub Pages当通过这个域名访问时强制使用HTTPS。这与Cloudflare的“始终使用HTTPS”是协同工作的不是冲突。如果问题依旧可以尝试在Cloudflare的“SSL/TLS” - “边缘证书”设置中暂时关闭“始终使用HTTPS”清空浏览器缓存再测试。如果关闭后正常说明问题出在Cloudflare的HTTPS重定向与某些配置冲突。可以检查Page Rules页面规则里是否有额外的重定向规则。标准配置Cloudflare SSL模式为“完全严格”开启“始终使用HTTPS”GitHub Pages自定义域名处勾选“Enforce HTTPS”。这个组合是经过验证的稳定配置。5.3 评论系统如Giscus不显示或加载失败问题描述按照文档配置了Giscus但页面上看不到评论框或者控制台报错。排查步骤检查仓库配置确保你的GitHub仓库确实已启用Discussions功能Settings - General - Features - Discussions。检查Giscus App安装访问 https://github.com/apps/giscus 确认已安装并授权给了你的博客仓库。可以配置为“All repositories”或仅此仓库。检查数据映射在giscus.app配置向导中“页面-Discussion映射关系”选择“URL pathname”。确保“Discussion分类”已正确创建通常在配置Giscus时会自动创建。检查前端代码核对嵌入的脚本代码中的> GitHub Pages博客重建实战：Jekyll+Cloudflare打造极速静态站点
1. 项目概述为什么我要重建我的GitHub Pages博客几年前我随手用Jekyll搭了个博客扔在GitHub Pages上想着能写点东西就行。那时候觉得免费、省心、能绑定域名还要啥自行车确实GitHub Pages这套组合拳——静态站点生成器加托管——对于技术分享、个人记录来说初期简直完美。但随着时间推移问题一个个冒出来了访问速度时快时慢尤其是在某些网络环境下主题老旧想改个样式发现当初选的主题文档不全牵一发而动全身更别提那些零散的插件和自定义配置连我自己都快忘了当初是怎么拼凑起来的。每次想写新文章都得先跟这个陈旧的系统“搏斗”一番写作的热情被磨掉大半。所以“重建”这个念头不是一时兴起而是一次彻底的“系统重装”。这次的目标很明确在保留GitHub Pages核心优势免费、与Git工作流无缝集成的前提下打造一个更快、更稳、更易维护的现代化静态博客。重建不是推倒重来那么简单它涉及到生成器选型、部署优化、CDN加速、评论系统迁移等一系列环节。简单说我想从一个“勉强能用”的状态升级到一个“用得顺手甚至有点享受”的状态。如果你也在用GitHub Pages但总觉得哪里差了点意思或者正准备从零开始搭建那么我踩过的坑、总结的方案或许能帮你省下不少折腾的时间。2. 核心需求与方案选型不止于“换个主题”重建的第一步是明确需求。我列了个清单问自己到底想要什么极致的访问速度与稳定性全球访问都应该是快速的且具备抗DDoS等基础安全能力。高度的可维护性与可定制性主题结构清晰文档齐全方便后续自定义样式和功能。平滑的内容迁移旧博客的文章Markdown文件必须能无损迁移URL结构最好也能保持这对SEO很重要。完整的博客生态评论、搜索、分析等周边功能需要易于集成。未来的扩展性能方便地集成自动化工作流比如自动部署、资源优化等。基于这些需求我评估了几个主流方案2.1 静态站点生成器SSG选型为什么最终还是Jekyll市面上SSG很多Hugo、Hexo、Next.js、Gatsby都很火。Hugo以编译速度著称Hexo生态丰富尤其对中文用户Next.js则代表了前沿的React框架。我为什么还是选了“老牌”的Jekyll原生集成与零配置GitHub Pages对Jekyll的支持是“亲生儿子”级别的。你只需要把符合Jekyll目录结构的代码推送到gh-pages分支或主分支的特定目录GitHub会自动识别、构建并部署。这意味着你完全不需要在本地或云端配置构建环境也无需关心依赖安装。对于追求简洁和“开箱即用”的场景这是巨大的优势。其他生成器大多需要配置GitHub Actions来实现自动构建多了一个环节就多了一份出错的概率。内容迁移成本最低我的旧博客就是Jekyll的文章都是Markdown文件Front Matter文章头部的YAML配置格式通用。迁移到另一个Jekyll主题几乎只需要复制粘贴文章文件并微调一下Front Matter中的标签分类即可。如果换用其他生成器虽然也有迁移工具但难免会遇到格式兼容性问题需要手动调整工作量不可控。足够的主题与插件生态Jekyll社区历史悠久有大量成熟、高质量的主题。更重要的是许多主题作者都考虑到了GitHub Pages的兼容性会避免使用需要额外构建步骤的插件。对于我的需求博客它的功能完全够用。当然Jekyll的缺点也很明显Ruby环境在非Mac/Linux系统上可能有点麻烦但GitHub Pages托管帮你省了这一步编译速度对于超大型站点可能较慢。但对于一个个人博客来说这些都不是核心痛点。选型的核心原则是用最少的持续维护成本满足核心需求。JekyllGitHub Pages的组合在“省心”这一点上目前依然很难被超越。2.2 主题选择从“功能堆砌”到“简洁核心”以前我喜欢找功能丰富的主题评论、相册、音乐播放器啥都有。这次我反其道而行之选择了一个结构极其清晰、代码注释完整、专注于写作和阅读体验的极简主题。原因有三专注博客的核心是内容。花里胡哨的功能会分散读者和自己的注意力。可维护简单的主题意味着更少的代码更清晰的逻辑。当我想自定义某个部分时我能很快找到对应的文件并理解其作用而不是在一堆复杂的模板和脚本中迷失。性能更少的JavaScript和CSS意味着更快的加载速度。很多功能可以通过外部服务如评论用Disqus或Gitalk搜索用Algolia来集成保持核心站点的轻量。我最终选择了一个基于minima主题深度定制并完全重写的开源主题它保留了Jekyll的标准目录结构但样式现代且所有布局文件_layouts/和包含文件_includes/都写得非常易懂。2.3 加速与安全方案引入Cloudflare CDN这是本次重建提升体验最关键的一步。GitHub Pages的服务器主要在美国国内访问速度不稳定是众所周知的痛点。直接解决方案就是加一层CDN内容分发网络。为什么是Cloudflare首先它免费套餐的功能对于个人博客来说已经非常强大全球CDN、DDoS防护、SSL证书支持灵活SSL和完全SSL、防火墙规则、缓存优化等。其次它的配置界面相对友好与域名服务的集成修改NS记录或CNAME是标准操作。核心价值加速用户访问你的博客blog.yourdomain.com时请求会先到达离他最近的Cloudflare节点。如果该节点有缓存直接返回速度极快如果没有Cloudflare会回源到你的GitHub Pages地址yourusername.github.io获取内容并缓存。对于静态资源图片、CSS、JS缓存效果显著。隐藏源站你的真实服务器GitHub PagesIP对公众是隐藏的由Cloudflare作为代理这在一定程度上提升了安全性。HTTPS无忧Cloudflare提供免费的SSL证书你只需要在控制台一键开启“SSL/TLS”的“完全”模式它就会帮你处理浏览器到Cloudflare、以及Cloudflare到GitHub Pages之间的加密无需自己在服务器上管理证书。注意使用Cloudflare CDN后你的访客和GitHub看到的访问IP都将是Cloudflare节点的IP这会导致GitHub Pages内置的访问日志统计失效也会影响一些基于IP的功能如果你有的话。通常这对于博客来说是可以接受的统计可以交给Google Analytics或Cloudflare自家的分析。3. 详细实施步骤从零到一的完整记录3.1 本地环境准备与主题初始化虽然GitHub Pages会自动构建但在本地预览和调试是必不可少的。你需要一个本地Jekyll环境。安装Ruby与Jekyll以macOS为例其他系统请参考官方文档# 使用Homebrew安装Ruby如果系统Ruby版本旧 brew install ruby # 将新安装的Ruby路径添加到shell配置如.zshrc echo export PATH/usr/local/opt/ruby/bin:$PATH ~/.zshrc source ~/.zshrc # 安装Jekyll和Bundler gem install --user-install bundler jekyll安装后运行jekyll -v和bundle -v确认安装成功。创建新博客项目jekyll new myblog --skip-bundle cd myblog--skip-bundle参数是为了先不安装依赖因为我们可能要换主题。替换主题 删除自动生成的minima主题相关文件主要是_layouts,_includes,_sass目录和index.md等然后将你选中的新主题文件全部复制过来。或者更推荐的方式是直接Fork或Clone你心仪的主题仓库以此作为起点。这样能保证目录结构完全正确。安装依赖并本地运行bundle install bundle exec jekyll serve访问http://localhost:4000你应该能看到新主题的预览效果。3.2 内容迁移与配置调整这是最需要耐心的一步。文章迁移将旧博客_posts目录下的所有.md文件复制到新项目的_posts目录。检查每篇文章的Front Matter确保关键字段如title、date、layout、categories、tags与新主题的要求一致。通常title和date是通用的layout可能需要根据新主题的布局文件名称修改如从post改为default。静态资源迁移将旧博客的图片、附件等资源通常在assets、images或uploads目录复制到新项目的对应目录。建议借此机会整理资源删除无用文件并使用压缩工具优化图片体积。配置文件_config.yml这是Jekyll的核心。你需要仔细配置title,description,url,baseurl站点基本信息。theme如果你用的主题是Gem-based这里填主题Gem名如果是直接复制文件的则删除或注释掉这一行。plugins列出需要的插件如jekyll-feedRSS、jekyll-sitemap站点地图。确保它们在Gemfile中也有定义。defaults为特定路径的文件设置默认Front Matter非常有用。例如可以为所有_posts下的文件默认设置layout: post。主题特定的配置如社交链接、评论设置Disqus shortname、Google Analytics ID等参考主题文档填写。测试与验证本地运行bundle exec jekyll serve逐一点开每篇文章检查格式是否正确、图片是否显示、链接是否有效。特别检查分类页和标签页是否正常工作。3.3 部署到GitHub Pages并绑定自定义域名创建GitHub仓库在GitHub上创建一个名为你的用户名.github.io的公开仓库。这是使用GitHub Pages个人站点的最简单方式。推送代码git init git add . git commit -m Initial commit with new blog git branch -M main git remote add origin https://github.com/你的用户名/你的用户名.github.io.git git push -u origin main等待构建推送后GitHub Actions会自动开始构建对于Jekyll项目。你可以在仓库的“Actions”标签页查看构建状态。成功后访问https://你的用户名.github.io就能看到新博客。绑定自定义域名在域名注册商处为你的域名例如blog.yourdomain.com添加一条CNAME记录指向你的用户名.github.io。在你的博客项目根目录下创建一个名为CNAME的文件无后缀里面只写一行你的域名blog.yourdomain.com。将CNAME文件提交并推送到GitHub仓库。在GitHub仓库的 Settings - Pages 页面Custom domain部分填入你的域名并保存。GitHub会尝试验证并为你自动配置一个用于验证的A记录你可以选择使用它也可以稍后在DNS处自己配置。建议先使用GitHub提供的验证方式成功后再进行下一步的CDN配置。3.4 配置Cloudflare CDN加速这是将访问体验提升一个档次的关键。将域名接入Cloudflare在Cloudflare官网注册并添加你的网站例如yourdomain.com。Cloudflare会扫描你现有的DNS记录并给出两个Cloudflare的Nameserver地址如lara.ns.cloudflare.com。回到你的域名注册商控制台将域名的Nameserver修改为Cloudflare提供的那两个。这个过程称为“更改NS记录”生效需要几小时到48小时。配置DNS记录等待NS生效后在Cloudflare的DNS管理页面你需要添加一条记录来指向你的博客。重要这里有两种方法方法A推荐更清晰为博客子域名单独设置。类型CNAME名称blog目标你的用户名.github.io代理状态已代理橙色云朵。方法B根域名如果你想用根域名yourdomain.com访问博客GitHub Pages要求配置A记录指向其IP。你需要添加多条A记录名称目标分别指向GitHub Pages的四个IP185.199.108.153,185.199.109.153,185.199.110.153,185.199.111.153代理状态同样开启。确保之前在GitHub仓库中创建的CNAME文件内容与你这里设置的记录一致例如blog.yourdomain.com。配置SSL/TLS在Cloudflare控制台的SSL/TLS选项卡下将加密模式设置为“完全严格”。这个模式要求从Cloudflare到你的源站GitHub Pages的连接也是加密的。由于GitHub Pages本身就支持HTTPS并提供有效证书所以这个模式是安全的。“边缘证书”部分确保“始终使用HTTPS”选项是开启的。这会将所有HTTP请求重定向到HTTPS。优化缓存与速度速度选项卡可以开启“Auto Minify”自动压缩HTML、CSS、JS代码。缓存选项卡这是重点。配置“缓存级别”为“标准”。在“缓存规则”中可以创建一条规则来缓存所有静态资源。例如创建一个页面规则如果URL匹配*blog.yourdomain.com/*.jpg或*.css或*.js则设置“缓存级别”为“缓存所有内容”并设置一个较长的“边缘缓存TTL”如一个月。对于博客文章页面HTML由于内容会更新缓存时间可以设短一些或者使用“标准”缓存级别并依靠Cloudflare的“浏览器缓存TTL”设置。验证等待DNS完全生效后访问你的自定义域名如https://blog.yourdomain.com。打开浏览器开发者工具的“网络”选项卡查看请求的响应头。你应该能看到CF-Cache-Status: HIT缓存命中或MISS未命中但下次访问可能就是HIT了以及Server: cloudflare等字样这表示流量已经成功经过Cloudflare加速。4. 周边功能集成与优化博客的核心是内容但一些周边功能能极大提升互动性和可管理性。4.1 评论系统从Disqus到更轻量的选择过去Disqus是标配但它臃肿、加载慢、有广告。现在有更优选择Giscus我目前使用的方案。它利用GitHub Discussions作为评论存储后端。访客使用GitHub账号登录即可评论。优点是完全免费、无广告、与开发者社区无缝集成评论内容以Issues的形式保存在你自己的仓库里数据自主。配置步骤确保你的博客仓库已启用Discussions功能Settings - General - Features - Discussions。安装Giscus App到你的仓库授权。访问 giscus.app 根据向导配置选择仓库、映射方式等生成一段脚本代码。将这段脚本代码嵌入到你的Jekyll主题的评论布局文件通常是_includes/comments.html中。Utterances与Giscus类似但使用GitHub Issues而非Discussions。原理和配置方式相近也是一个轻量级的好选择。Twikoo一个基于云函数的评论系统支持多种登录方式界面美观。需要自行部署一个后端云函数如Vercel、腾讯云SCF稍微复杂一点但可控性更强。实操心得对于技术博客Giscus非常合适因为读者大概率有GitHub账号。它的加载速度比Disqus快得多且没有隐私顾虑。唯一的“门槛”是访客需要有GitHub账号。4.2 站内搜索让内容更容易被找到静态站点无法进行服务端搜索需要借助前端JavaScript或第三方服务。Simple Jekyll Search一个纯客户端的JavaScript搜索库。它会在构建时生成一个包含所有文章标题、内容和URL的JSON文件search.json。访客搜索时JS直接在这个JSON文件里进行匹配。优点是完全免费、无需外部依赖、隐私友好。缺点是文章数量巨大时比如上千篇JSON文件会比较大影响初始加载且搜索算法相对简单。集成方法在_config.yml中配置生成search.json。然后在主题中引入其JS文件并添加一个搜索输入框和结果展示容器。很多Jekyll主题已经内置了此功能。Algolia专业的搜索即服务。它能提供更快、更相关、支持拼音纠错等高级功能的搜索体验。它提供免费的社区套餐每月一定额度的搜索次数和记录数对个人博客通常够用。但需要将你的站点内容通过API或自动化脚本推送到Algolia配置步骤稍多。我选择了Simple Jekyll Search因为它足够简单且与静态博客“自给自足”的理念更契合。对于几百篇文章的博客其性能完全可接受。4.3 自动化与持续集成让更新更省心虽然GitHub Pages已经自动化了构建部署但我们还可以做得更好自动提交Sitemap到搜索引擎每次博客更新都希望Google、Bing能尽快收录。可以在_config.yml中启用jekyll-sitemap插件自动生成sitemap.xml。然后可以利用GitHub Actions在每次推送代码后自动向Google Search Console等平台提交这个sitemap。这需要你配置一个包含相应API调用的Action工作流文件.github/workflows/submit-sitemap.yml。资源优化可以在本地构建流程中集成图片压缩工具如imagemin或者使用GitHub Actions在构建前自动压缩图片。同样也可以集成CSS/JS的压缩和合并工具。链接检查定期运行死链检查确保博客没有失效的链接。可以设置一个每周运行的GitHub Action使用lychee或linkchecker这样的工具扫描你的站点并将报告发送到你的邮箱或生成一个Issue。这些自动化脚本一开始可能觉得麻烦但一旦设置好就是一劳永逸的“数字管家”能帮你维护博客的健康状态。5. 常见问题与排查实录在重建和后续维护过程中我遇到了不少典型问题这里记录下排查思路。5.1 本地运行正常推送到GitHub后页面空白或样式错乱问题描述bundle exec jekyll serve本地预览一切完美但推送到GitHub Pages后访问网站发现只有纯文本没有CSS样式或者布局全乱。排查步骤检查_config.yml中的url和baseurl这是最常见的原因。url应设置为你的最终访问地址如https://blog.yourdomain.combaseurl如果你站点不在根路径则设置例如/blog否则就留空。本地运行时Jekyll可能会忽略这些设置或使用默认值但GitHub Pages构建时会严格使用这些值来生成资源链接。错误的baseurl会导致所有CSS/JS的链接路径错误。检查GitHub Pages构建日志在仓库的“Actions”标签页找到最新的Pages构建工作流点开查看详细日志。构建失败Build failed会直接导致站点无法更新。常见失败原因使用了GitHub Pages不支持的自定义插件白名单外的插件、Ruby版本不兼容、Gemfile中依赖冲突或语法错误。检查主题引用方式如果你使用的是Gem-based主题确保_config.yml中theme设置正确且Gemfile中包含该主题gem。如果你是把主题文件直接复制到项目里的确保_config.yml中没有theme这一项或者已被注释掉否则Jekyll会去寻找一个不存在的Gem。使用github-pagesGem在Gemfile中使用gem github-pages, group: :jekyll_plugins并运行bundle update github-pages。这个Gem包确保了本地环境与GitHub Pages服务器环境的一致性能最大程度避免“本地行线上不行”的问题。5.2 Cloudflare CDN配置后访问出现“重定向过多”错误问题描述配置Cloudflare并开启“始终使用HTTPS”后访问网站出现ERR_TOO_MANY_REDIRECTS错误。原因与解决这是SSL/TLS设置和源站配置冲突的典型表现。首先确认Cloudflare的SSL/TLS加密模式。强烈建议使用“完全严格”模式。如果使用“灵活”模式浏览器到Cloudflare是HTTPSCloudflare到GitHub Pages是HTTP而GitHub Pages又强制跳转HTTPS就可能形成循环重定向。其次检查你的GitHub Pages仓库设置。在Settings - Pages - Custom domain下确保“Enforce HTTPS”复选框是勾选的。这个选项告诉GitHub Pages当通过这个域名访问时强制使用HTTPS。这与Cloudflare的“始终使用HTTPS”是协同工作的不是冲突。如果问题依旧可以尝试在Cloudflare的“SSL/TLS” - “边缘证书”设置中暂时关闭“始终使用HTTPS”清空浏览器缓存再测试。如果关闭后正常说明问题出在Cloudflare的HTTPS重定向与某些配置冲突。可以检查Page Rules页面规则里是否有额外的重定向规则。标准配置Cloudflare SSL模式为“完全严格”开启“始终使用HTTPS”GitHub Pages自定义域名处勾选“Enforce HTTPS”。这个组合是经过验证的稳定配置。5.3 评论系统如Giscus不显示或加载失败问题描述按照文档配置了Giscus但页面上看不到评论框或者控制台报错。排查步骤检查仓库配置确保你的GitHub仓库确实已启用Discussions功能Settings - General - Features - Discussions。检查Giscus App安装访问 https://github.com/apps/giscus 确认已安装并授权给了你的博客仓库。可以配置为“All repositories”或仅此仓库。检查数据映射在giscus.app配置向导中“页面-Discussion映射关系”选择“URL pathname”。确保“Discussion分类”已正确创建通常在配置Giscus时会自动创建。检查前端代码核对嵌入的脚本代码中的>