搭建图床

在 GitHub 上搭建图床（Image Hosting）是一个非常受开发者欢迎的选择，因为它免费、稳定，且能很好地集成到 Markdown 文档中。

以下是搭建 GitHub 图床的完整步骤以及常用的辅助工具：

1. 基础准备工作

在 GitHub 上，你需要一个专门存放图片的仓库。

  1. 创建仓库：新建一个 Public（公开）仓库，例如命名为 image-hosting。
  2. 获取 Token：为了让第三方工具能上传图片，你需要生成一个 Personal Access Token (Classic)。
    • 路径：Settings -> Developer settings -> Personal access tokens -> Tokens (classic)。
    • 权限：勾选 repo 权限即可。
    • 注意：Token 只会出现一次，记得复制保存。

2. 核心挑战：CDN 加速

由于 GitHub 的服务器在国内访问速度较慢，直接引用原图链接可能导致加载缓慢或无法显示。通常我们会配合 jsDelivr 进行加速。

  • GitHub 原图链接：https://raw.githubusercontent.com/[用户名]/[仓库名]/master/[路径]/[文件名]
  • jsDelivr 加速链接：https://cdn.jsdelivr.net/gh/[用户名]/[仓库名]@[分支名]/[路径]/[文件名]

3. 推荐的上传辅助工具

手动上传太麻烦，通常配合以下工具实现“一键上传并自动复制链接”：

PicGo (首选推荐)

PicGo 是目前最流行的开源图床管理工具，支持 Windows, macOS 和 Linux。

  • 特点：支持拖拽上传、剪贴板上传，自动转换成 Markdown 格式。
  • 配置：在 PicGo 中选择 GitHub 图床，填写仓库名、分支（通常是 main 或 master）、Token 以及存储路径。

PicList

PicGo 的增强版，功能更强大，支持图片压缩、水印、管理云端文件等。

Obsidian / VS Code 插件

如果你在写博客，可以直接在编辑器内安装插件（如 Image Auto Upload），实现粘贴图片即自动上传到 GitHub。

4. GitHub 图床的优缺点分析

优点 缺点
完全免费，无容量限制（建议单仓库不超过 1GB） 国内直连速度不稳定，依赖 CDN
仓库私有化管理，数据自主掌控 严禁上传违规图片，否则可能封号
配合 jsDelivr 访问速度极快 GitHub 仓库超过 1GB 或单文件过大会有限制

5. 进阶建议

  • 图片压缩：上传前建议先压缩图片（TinyPNG 等），节省空间并加快加载。
  • 防止失效：由于 jsDelivr 在国内偶尔波动，建议重要的图片同时备份到其他平台（如 Gitee 或 阿里云 OSS）。

jsDelivr和GitHub的关系

简单来说，GitHub 是你的“仓库”（存放图片的地方），而 jsDelivr 是你的“快递公司”（把图片快速送到用户面前）。

它们之间的关系可以拆解为以下三个核心点：

1. 存储与分发的关系

  • GitHub (源站)：负责静态文件的持久化存储。由于 GitHub 的服务器主要在海外，国内直接访问 GitHub 仓库中的原始图片（raw.githubusercontent.com）往往会非常缓慢，甚至连接超时。
  • jsDelivr (CDN 加速)：是一个免费的开源 CDN 平台。它实时“镜像”了 GitHub 的内容。当你通过 jsDelivr 链接请求一张图片时，它会先去 GitHub 抓取，然后缓存到它遍布全球（包括中国节点）的加速服务器上。

2. 链接转换的逻辑

你不需要在 jsDelivr 上做任何注册或上传操作。只要你的 GitHub 仓库是 Public（公开） 的，jsDelivr 就能自动识别。其链接转换规律如下：

  • GitHub 原始地址： https://github.com/用户名/仓库名/blob/分支名/图片路径.jpg
  • jsDelivr 加速地址： https://cdn.jsdelivr.net/gh/用户名/仓库名@分支名/图片路径.jpg

提示：如果在 @分支名 处不写分支，默认会抓取最新提交的内容。为了稳定性，建议加上版本号或分支名，例如 @main 或 @v1.0。

3. 为什么大家总把它们放在一起说？

在搭建“免费图床”这个场景下，它们是黄金搭档：

  1. 优势互补：GitHub 解决了免费空间问题，jsDelivr 解决了国内访问速度和流量消耗问题。
  2. 自动化流程：很多工具（如 PicGo）支持一键上传到 GitHub 后，自动根据规则生成 jsDelivr 的链接。
  3. 高可靠性：即便 GitHub 临时挂了，只要 jsDelivr 的缓存还在，你的图片依然可以正常显示。

⚠️ 重要提醒：当前的现状

虽然这个方案曾经非常流行，但你需要了解：

  • 政策风险：jsDelivr 在国内的备案和节点状态偶尔会有波动（比如 2021 年底其国内域名曾被吊销备案），导致部分地区访问受阻。
  • 使用规范：jsDelivr 官方并不鼓励将该服务作为大规模商业图床使用。如果单文件过大（超过 20MB）或流量异常巨大，可能会被限制。

Personal Access Token和ssh私钥的关系

简单来说，Personal Access Token (PAT) 和 SSH 私钥 都是用来在本地 Git 客户端和远程仓库（如 GitHub、GitLab）之间证明“你是你”的凭证。

你可以把它们理解为：

  • PAT：一种专门给程序用的、带有权限限制的“超级临时密码”。
  • SSH 私钥：一根“专属实体钥匙”，通过复杂的数学匹配（非对称加密）来开锁。

核心区别对比

特性 Personal Access Token (PAT) SSH 私钥 (SSH Key)
底层协议 HTTPS (端口 443) SSH (端口 22)
工作原理 充当“密码”，在每次请求时通过 HTTP 报头发送。 客户端用私钥签名，服务器用公钥验证。私钥永不通过网络传输。
权限控制 非常精细。可以设置只读、只能访问特定仓库、有效期等。 较粗放。通常拥有该用户账号下的所有操作权限（除非专门配置 Deploy Key）。
使用场景 脚本自动化、API 调用、由于防火墙限制无法使用 SSH 的环境。 开发者的日常工作（Push/Pull），通常配置一次后永久生效，体验更顺滑。
安全性 类似密码，一旦泄露，拿到 Token 的人就能直接用。 极高。私钥保存在本地，且可以设置密码（Passphrase）进行二次加密。

1. Personal Access Token (PAT)

由于 GitHub 等平台已经禁用了直接使用“账号+密码”进行 Git 操作，PAT 实际上是密码的替代品。

  • 优点：
    • 安全性高（相对密码）：你可以生成一个有效期只有 30 天的 Token，过期自动作废。
    • 职责单一：比如你可以创建一个只能“读取代码”的 Token 给 CI/CD 机器人，即便泄露了，别人也无法删你的仓库。
    • 兼容性好：只要能上网（HTTPS）就能用，不受公司防火墙封禁 22 端口的影响。
  • 缺点：
    • 管理起来较麻烦，如果没保存好，Token 丢失后无法找回，只能重新生成。

2. SSH 私钥

SSH 采用的是“非对称加密”：你把公钥给 GitHub，自己留着私钥。

  • 优点：
    • 配置简单：在本地生成一对密钥，把公钥往 GitHub 设置里一贴，之后所有操作都不再需要输入任何东西。
    • 私密性：你的私钥永远留在你的电脑里，不像 Token 可能会在配置某些环境变量时被无意中打印到日志里。
    • 签名功能：SSH Key 还可以用来给 Git 提交进行签名（Signing commits），证明这行代码确实是你写的。
  • 缺点：
    • 权限控制不够灵活（通常是全开或全关）。
    • 部分严格的公司网络环境会封锁 SSH 协议的端口。

我该选哪一个？

  • 如果你是个人开发者，在自己的电脑上写代码：

    首选 SSH。配置一次，终身受益。

  • 如果你在写脚本、配置 Jenkins 自动化流水线：

    首选 PAT。可以精确控制权限，且易于通过环境变量注入。

  • 如果你的网络环境非常特殊（比如只能用浏览器上网）：

    只能选 PAT (HTTPS)。