Test3
Test3
Test3
Test2
Test1
Gmeek.yml原有 GitHub Actions ,通过 actions/upload-pages-artifact@v3 和 actions/deploy-pages@v4 自动化部署到本仓库的虚拟机上(注:不知这样理解是否正确)。
1 | name: build Gmeek |
.yml 修改需求源仓库生成相关文件后,将静态页面 ./docs 下的文件推送到博客仓库分支 gh-pages 上,即网站部署在分支。
shenjuexiao/gmeek-sourceshenjuexiao/gmeek-docsgh-pages 分支peaceiris/actions-gh-pages${{ secrets.GMEEK_DOCS }}
注释掉本地的部署
1 | # 不需要配置 GitHub Pages |
1 | # 去掉源仓库的部署 |
1 | # 去掉源仓库的部署 |

源仓库需要设置 token
Personal access tokens (classic)Settings -> Developer settings -> Personal access tokens -> Tokens (classic)Repository secretsSettings -> Secrets and variables -> Actions -> New repository secretgmeek-docs.yml1 | name: build Gmeek |
GitHub仓库里的CNAME文件,核心作用是告诉GitHub Pages服务器,当用户通过你的自定义域名(比如 www.example.com)访问时,应该展示哪个仓库的网站内容。
你可以把它理解为在GitHub内部为你的域名和特定仓库建立的一个“认领”和“关联”关系。它需要在你的域名解析服务商(如阿里云、Cloudflare)设置的DNS解析配合下才能正常工作。
当用户在浏览器输入你的自定义域名(如 www.example.com)并访问时,流程如下:
www.example.com指向哪里。你需要在DNS服务商那里添加一条 CNAME记录,将 www.example.com 指向 你的用户名.github.io。这一步把域名指向了GitHub的服务器。CNAME(必须大写)的文件。CNAME文件内容(例如www.example.com),与用户请求的域名完全匹配时,它就知道要把这个仓库的网站内容返回给用户了。两者的关系:分工明确的“钥匙”与“路标”。这两者缺一不可,它们共同完成从“自定义域名”到“具体 GitHub 仓库”的映射。
| 组成部分 | 作用概括 | 配置位置 | 关键点 |
|---|---|---|---|
| 仓库 CNAME 文件 | “钥匙”:授权并告诉 GitHub,哪个域名可以访问这个仓库 | 仓库根目录下的 CNAME 文件 | 内容必须与 DNS 记录的子域名一致,且只能有一个域名 |
| DNS CNAME 记录 | “路标”:将互联网流量从你的域名指向 GitHub 服务器 | 域名注册商/DNS 服务商的管理后台 | 通常用于 www 子域名,指向<用户名>.github.io |
CNAME文件“占用”了,其他仓库就无法再使用该域名,除非你将其删除。*.example.com)。因为任何GitHub用户都可以在自己的仓库里创建一个指向你任意子域名的CNAME文件,从而可能“劫持”你的子域名来托管他们的内容。CNAME文件中只能包含一个域名。如果你想把多个域名都指向同一个网站,可以通过你的DNS服务商设置URL转发或使用其他DNS记录来实现。CNAME文件放在项目的源文件夹(如source目录)下。这样每次部署时,它就会被自动复制到生成的public文件夹并推送到GitHub,避免每次部署后CNAME文件丢失的问题。docs.astro.build/zh-cn/install-and-setup/
我选择的是 Astro Use blog template,也可以选择其他的选项,使用模板能快速建立页面。

1 | # 使用 npm 创建一个新项目 |
或
1 | # 使用 pnpm 创建一个新项目 |
或
1 | # 使用 yarn 创建一个新项目 |

docs.astro.build/zh-cn/basics/project-structure/
Astro 采用一套约定俗成的文件夹布局来管理项目。每个 Astro 项目的根目录下都应该包括以下目录和文件:
docs.astro.build/zh-cn/develop-and-build/
Astro 自带了一个内置的开发服务器,它包含了项目开发所需的一切。astro dev CLI 命令将启动本地开发服务器,让你第一次看到你的新网站。
每个起始模板都预配置了一个脚本,该脚本将为你运行 astro dev。在进入你的项目目录后,使用你喜欢的包管理器运行此命令并启动 Astro 开发服务器。
1 | npm run dev |
或
1 | pnpm run dev |
或
1 | yarn run dev |
docs.astro.build/zh-cn/guides/deploy/github/
1 | name: Deploy to GitHub Pages |

这个错误表明 GitHub Pages 部署失败,主要原因是 GitHub Pages 没有在仓库设置中启用。错误信息明确指出:
Ensure GitHub Pages has been enabled: https://github.com/shenjuexiao/astro/settings/pages
npm 和 npx 是 Node.js 生态里两个核心但职责不同的工具,可以用一句话来区分它们:
npm 是“包管理器”,负责安装、管理依赖;而 npx 是“包执行器”,负责运行命令,无需显式安装。
| 特性 | npm (Node Package Manager) | npx (Node Package Execute) |
|---|---|---|
| 核心职责 | 管理项目的依赖包,比如安装、卸载、更新、发布包 | 执行某个 Node.js 包提供的命令 |
| 是否需要安装 | 需要。包会被下载并保存到 node_modules 或全局目录 |
通常不需要。它会临时下载并执行,用完即走,不污染环境 |
| 典型场景 | 为项目安装核心依赖(如 npm install react)运行 package.json 中定义的脚本(如 npm run build) |
运行一次性的脚手架工具(如 npx create-react-app my-app)快速测试不同版本的包(如 npx webpack@4.44.1 -v) |
| 执行本地包 | 需要通过 ./node_modules/.bin/ 路径或 npm run 命令间接运行 |
可以直接运行,它会自动在 node_modules/.bin/ 中查找命令 |
除了用法上的不同,npx 还有一个非常便利的特性:它可以临时下载并运行一个远程的 npm 包,这在测试新工具或运行一次性脚本时能帮你节省不少时间。
一个很实用的场景是:创建 React 项目时,会先全局安装 create-react-app,再用它生成项目。有了 npx,可以直接 npx create-react-app my-app,不用全局安装,每次用的还都是最新版,非常方便。
一句话总结就是:
npm install。npx。raw.githubusercontent.com 和 cdn.jsdelivr.net/gh
简单来说,raw.githubusercontent.com 是图片在 GitHub 上的源服务器地址,而 cdn.jsdelivr.net/gh 则是一个免费的 CDN 加速服务,它的核心作用就是为前者"提速"。
下面是它们在几个关键维度上的直接对比:
| 对比维度 | raw.githubusercontent.com (源站) |
cdn.jsdelivr.net/gh (CDN) |
|---|---|---|
| 核心作用 | 直接访问 GitHub 服务器上的原始文件 | 通过全球 CDN 节点缓存并分发文件,进行加速 |
| 访问速度 | 通常较慢,尤其在中国大陆地区,延迟高,加载不稳定 | 显著更快,利用全球边缘节点就近响应,可大幅缩短加载时间 |
| 稳定性与限制 | 存在请求频率限制 (Rate Limit),高并发或大量图片时可能返回 HTTP 429 错误,导致图片无法加载 | 通常无严格的请求限制,但有单文件 50MB 的大小限制,且仅支持公开仓库 |
| 缓存机制 | 缓存策略较弱,重复访问可能仍需重新下载 | 具备强大的缓存机制(默认缓存24小时或更久),重复访问直接从 CDN 节点读取,速度极快 |
| URL 格式示例 | https://raw.githubusercontent.com/用户名/仓库名/分支名/图片路径.png |
https://cdn.jsdelivr.net/gh/用户名/仓库名@分支名或版本号/图片路径.png |
虽然 jsDelivr 优势明显,但在国内使用时需要留意一个已知风险:
国内 DNS 污染问题:jsDelivr 的官方域名 cdn.jsdelivr.net 在国内曾因DNS污染导致访问失败。如果你遇到这种情况,可以考虑使用它未被污染的备用域名,例如 fastly.jsdelivr.net 或 gcore.jsdelivr.net 作为替代方案。
cdn.jsdelivr.net/gh**。它能带来质的飞跃,让图片"秒开"不再困难,综合体验完胜直连源站。raw.githubusercontent.com 的适用场景**:主要用于在 GitHub 页面上直接预览文件内容,或在你需要从服务器后台程序以编程方式获取文件原始内容时使用。获取必应每日一图,主要有官方接口和第三方封装接口两种方式,按需选择即可。
Bing 官方提供了获取每日壁纸元数据的接口,这是最可靠的方式。
1 | https://cn.bing.com/HPImageArchive.aspx |
| 参数 | 说明 | 可选值示例 |
|---|---|---|
format |
必填。指定返回的数据格式 | js (JSON格式) 或 xml |
idx |
必填。图片的日期偏移量。0代表今天,1代表昨天,依此类推,最多可获取前16天的图片 |
0, 1, 2 |
n |
必填。返回的图片数量,最大为8 |
1, 3, 8 |
mkt |
地区/语言参数,影响图片说明和版权信息的语言 | zh-CN (中文), en-US (英文) |
uhd |
是否请求4K超高清图片。1表示请求 |
1 |
https://cn.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1&mkt=zh-CN1 | { |
你需要在url前拼接上Bing的域名 https://cn.bing.com 才能得到完整图片地址。
如果你不想自己处理数据,可以直接使用第三方封装好的接口,它们通常会直接返回图片或更简洁的JSON数据。
bing.biturl.top 功能全面的替代API这个接口将官方数据封装得很简洁,支持指定分辨率和直接重定向到图片,非常方便。
https://bing.biturl.top/?resolution=UHD&format=json&index=0&mkt=zh-CNhttps://bing.biturl.top/?resolution=1920&format=imageresolution支持UHD(4K)、1920、1366等;index支持0(今天)、1(昨天)或random(随机)。npanuhin/Bing-Wallpaper-Archive 强大的历史归档项目如果你想获取更久远的壁纸,这个项目维护了完整的图片归档。它按国家和语言组织数据,并且可以直接通过日期拼接图片地址,非常实用。
获取归档数据*https://bing.npanuhin.me/CN-zh.json
直接获取图片https://bing.npanuhin.me/CN/zh/2024-01-16.jpg (替换日期即可)
根据搜索结果,还有一些可用的API服务,如 https://api.1314.cool/bingimg 和 https://api.sunweihu.com/api/bing1/api.php,使用时请注意其稳定性。
1 | // 使用官方API获取今日壁纸URL并显示 |
1 | PS D:\\Git\\shenjuexiao> git remote set-url --delete gitee git@gitee.com:shenjuexiao/shenjuexiao.git |
这个错误是因为你试图删除远程仓库 gitee 的唯一 URL,Git 不允许这样做——每个远程仓库至少需要保留一个 URL。
1 | # 先添加一个新的 URL |
1 | # 直接替换整个 URL,而不是删除 |
1 | # 删除整个远程仓库 |
1 | # 查看 gitee 远程仓库的所有 URL |
如果你是想修改远程仓库地址,直接用方案二最简单:
1 | git remote set-url gitee git@gitee.com:新的仓库地址.git |
如果你是想添加多个推送地址(同时推送到多个仓库),用方案一。
1 | git remote rename github origin |
这个命令会:
github 重命名为 origingithub/main → origin/main)1 | # 查看所有远程仓库 |
你应该能看到类似这样的输出:
1 | origin git@github.com:你的用户名/仓库名.git (fetch) |
origin 已经存在,这个命令会报错。你需要先删除或重命名现有的 originorigin 已经指向其他仓库,可以先确认一下:1 | # 查看当前 origin 指向哪里 |
如果 origin 已经存在且不是你想用的,可以先删除它:
1 | git remote remove origin |
执行后记得检查一下 git remote -v 确认结果正确。