1. 方案选型：为什么是Typora、PicGo与Gitee
1.1 博客图片管理的痛点
写博客的人几乎都经历过这样的尴尬：本地笔记里插图一切正常，文章一发布到博客平台，图片全部变成裂开的图标，或者加载慢得像在等火车。归根结底是图片的存储位置出了问题——本地路径只能自己看，网络路径如果选错了服务商，要么收费要么龟速。
图片管理这件事，表面上是“存哪儿”的问题，实际牵扯到三个层面：图片能不能被公网访问、访问速度快不快、成本能不能接受。早期的做法是把图片传到博客平台自身的服务器，但换平台就得重新传一遍，图片域名还被平台锁死。后来有人用对象存储，稳定是稳定，但流量一上去，账单也上去了，个人博客那点流量又用不满，怎么看都亏。
我的选择标准很简单：免费、稳定、国内访问快、能长期持有。三个条件筛下来，剩下的方案其实不多。
1.2 三件套的分工与组合逻辑
Typora负责写，PicGo负责传，Gitee负责存。这三者各有各的专长，拼在一起刚好形成一条完整的链路：
- Typora是一款本地Markdown编辑器，所见即所得，写文档时图片直接拖进编辑器就能看到效果，不需要在源码和预览之间来回切。它自带了“上传图片”功能，可以把图片发送到外部工具处理，这种设计为图床方案留好了接口。
- PicGo是专门处理图片上传的桌面工具，支持多种图床，自带压缩、重命名、日志等功能，稳定且开源。它的核心价值是把“上传图片”这件事从手动操作变成自动化。
- Gitee是国内的代码托管平台，支持创建仓库存放静态文件，仓库里的图片可以通过固定链接直接访问。虽然它的定位不是图床，但个人博客的图片量完全够用，而且国内服务器的访问速度是明显优势。
这个组合的巧妙之处在于，每个工具只做自己最擅长的事，彼此之间通过标准接口协作。Typora不需要知道图片传到了哪里，PicGo不需要关心文章内容，Gitee只负责把文件存好并提供访问链接，三者零耦合，任何一环都能单独替换。
1.3 潜在替代方案对比
这里我把几种常用方案放在一起做了个对照，方便你判断自己的场景适合哪种：
| 方案 | 成本 | 国内访问速度 | 稳定性 | 维护复杂度 |
|---|---|---|---|---|
| Gitee图床 | 免费 | 快 | 中等（需注意仓库规则） | 低 |
| 对象存储（按量付费） | 低 | 快 | 高 | 低 |
| 国外代码托管平台 | 免费 | 慢或极不稳定 | 中等 | 低 |
| 博客平台自带图库 | 免费 | 取决于平台 | 高 | 高（换平台需迁移） |
如果你只写技术博客且图片量不大，Gitee图床是我目前用下来性价比最高的方案。当然，对象存储的稳定性天花板更高，这一点我在文末还会聊到。
2. 环境准备与基础配置
2.1 安装Typora与PicGo
Typora的安装没什么特殊之处，直接去官网下载对应系统的安装包，一路默认选项装完即可。这里提醒一句：Typora从某个版本开始收费，但买断制的价格对写作者来说完全可以接受，而且支持多设备授权，订阅前可以先用免费版体验完整功能。
PicGo的安装同样简单，但版本选择有个讲究。我建议直接用最新Release版本，不要用旧版，因为新版对Gitee图床的支持更完善，某些旧版在配置Gitee时还需要额外安装插件，这会给新手造成不必要的困惑。
装完PicGo后，先打开它的主界面认识一下布局。左侧是功能菜单，包含上传区、图床设置、相册、日志等；右侧是配置面板。第一次打开时，图床设置里默认是空的或只有部分预设，不要慌，后面会一步步配好。
2.2 注册Gitee账号与创建仓库
Gitee账号注册就跳过细节了，手机号加密码就能搞定。注册完成后先做两件事：绑定邮箱和实名认证。实名认证是必须的，否则后续创建仓库和生成令牌都会受限。
创建仓库的路径是：右上角“+”号 → 新建仓库。这里有几个关键选项需要说明一下：
- 仓库名称：建议全小写英文字母加连字符，比如
my-blog-images，不要用中文或空格，否则生成的图片链接里会出现转义字符，后续处理很麻烦。 - 是否开源：这里有两种选择。如果设为私有仓库，生成的图片链接在未登录状态下无法访问，只能在PicGo配置中开启“私人令牌”方式访问；如果设为公开仓库，所有人都能直接访问图片链接，但仓库内容也完全公开，除了图片没有隐私负担。
- 初始化仓库：建议勾选“初始化仓库”，会自动生成README文件，方便确认仓库正常。
我个人的习惯是直接用公开仓库。博客配图本来就是要给别人看的，设为私有只会给自己增加不必要的复杂度。如果实在介意隐私，可以在仓库里只放图片和README，不涉及任何隐私内容。
2.3 生成Gitee私人令牌
这一步是很多人卡住的地方。Gitee出于安全考虑，不允许直接用密码访问仓库API，必须通过令牌（Token）认证。生成路径是：Gitee头像 → 设置 → 安全设置 → 私人令牌 → 生成新令牌。
生成令牌时有几个权限项要勾选，关键在于：
- projects：必须勾选，这是访问仓库内容的权限
- user_info：可选，部分场景下PicGo会读取用户信息，勾上更稳妥
生成后，Gitee只会显示一次令牌内容，一定要立即复制保存到本地文本文件里，后面配置PicGo时要用。如果弄丢了，只能删除旧令牌重新生成，这个坑我已经踩过一次了，这里重点提醒。
注意：令牌等同于密码，别传到公开仓库、博客文章或任何能被别人看到的地方。泄露令牌等于别人可以任意操作你的仓库，包括删除文件。
3. PicGo配置Gitee图床的实操细节
3.1 在PicGo中配置仓库参数
打开PicGo，进入“图床设置”，选择Gitee图床。如果没有这个选项，需要先到插件市场搜索安装gitee-uploader插件，安装完成后重启PicGo。
配置面板里需要填四项内容：
- repo：格式是
用户名/仓库名，比如zhangsan/my-blog-images。这个格式特别容易写错，有些人填成仓库的完整URL，有些人只填仓库名，都会导致上传失败。注意只填用户名加斜杠加仓库名，不带https://前缀。 - branch：填
master。如果仓库默认分支是main，需要先在Gitee仓库设置里把默认分支改成master，或者把这里填成main。两种方式都可以，关键是保持一致。 - token：粘贴上一步保存的私人令牌。
- path：图片在仓库里的存放目录。填
img/表示放到img目录下，也可以直接留空放在仓库根目录。我建议填一个目录名，方便后期管理和迁移。
配置完成后，点击“设为默认图床”，然后在上传区拖入一张测试图片。如果上传成功，PicGo会返回一个图片链接，这就是后续博客里引用的图片地址。
3.2 定制提交信息与URL路径
PicGo的Gitee图床配置里还有两个容易被忽略的选项，分别是“自定义提交信息”和“URL路径”，它们的作用不同但都很实用。
自定义提交信息是每次上传图片时Gitee仓库里生成的commit记录。默认情况下提交信息是Upload image之类的固定文案，如果想通过提交记录追踪图片来源，可以把它改成Upload image via PicGo这类有辨识度的内容。对于个人博客来说这个意义不大，但如果你习惯通过Gitee的提交记录审核内容，这个功能就有价值了。
URL路径的设置则需要特别注意。默认情况下，PicGo生成的图片链接是用户名.gitee.io/仓库名/文件夹名/文件名，这是因为Gitee默认开启了Pages服务。但实际上，图片的直接访问地址应该是gitee.com/用户名/仓库名/raw/分支/文件夹名/文件名。如果直接使用PicGo生成的默认链接，在某些场景下图片加载会出现异常。
我的做法是在PicGo的URL路径中手动填入完整的路径前缀，确保生成的链接是以raw开头，这样才能保证任何设备上都能正常访问图片。
技巧：配置完成后，用浏览器直接打开返回的图片链接测试，如果在未登录Gitee的状态下也能正常显示，说明配置正确；如果提示权限不足或404，优先检查仓库是否公开、分支名和路径是否匹配。
3.3 图床参数验证与常见配置错误
我在帮身边的人配置这套环境时，遇到最多的问题集中在以下三类：
- 仓库路径和分支写错，导致上传时提示
repository not found。解决方法是去Gitee仓库页面确认一下仓库路径和默认分支名，特别注意默认分支是master还是main。 - 令牌权限不足，上传时提示
403 Forbidden。解决方法是回到Gitee令牌设置页面，检查是否勾选了projects权限，必要时重新生成一个令牌。 - 插件未生效，配置界面里没有Gitee图床选项。解决方法是确认插件已经安装且版本与PicGo匹配，然后彻底退出程序重新打开。
这些问题的排查思路其实通用：先验证认证信息（令牌、账号）是否有效，再验证地址信息（仓库、分支、路径）是否正确，最后看工具本身的日志输出。PicGo的日志面板会记录详细的请求过程和返回信息，绝大多数问题都能从日志里直接定位。
4. Typora与PicGo的联动配置
4.1 打开Typora的图像设置
Typora的图像功能藏在菜单栏“文件 → 偏好设置 → 图像”里。默认情况下，插入图片只是复制到本地某个路径，并不会上传。我们要做的就是把默认行为改成“上传图片”，并且指定上传服务为PicGo。
具体操作如下：在“图像”设置页面，找到“插入图片时”选项，选择“上传图片”。然后在“上传服务设定”里选择“PicGo(app)”，再点击“PicGo路径”后面的浏览按钮，选择PicGo的安装程序路径。
这里有一个细节：Typora不会主动启动PicGo，它需要PicGo进程已经在后台运行，才能把图片传给PicGo上传。所以配置完成后，先手动打开一次PicGo，确认它在系统托盘里正常驻留，再回到Typora测试。
4.2 验证联动是否生效
配置完成后，建议做一个完整的链路测试。在Typora里新建一个文档，插入一张本地图片，然后观察几个现象：
- 图片下方是否出现“上传中”的提示，并且很快变成正常显示的图片
- 图片路径是否自动变成了
https://开头的网络地址 - 打开PicGo上传日志，是否出现一条成功记录
如果以上现象都正常，说明整条链路已经跑通。这时候可以做个极端测试：把Typora里引用的图片地址复制到无痕浏览器窗口访问，确认可以正常显示。因为某些情况下，本机浏览器会读取缓存导致误判，无痕模式能排除这个干扰。
4.3 配置完成后写文章的完整工作流
环境搭好之后，我的日常写作流程是这样的：
- 写文章前先在PicGo托盘图标上确认程序已在运行
- 打开Typora，直接开始写作，需要配图时把截图或图片拖进编辑区
- Typora自动将图片上传到Gitee，并把引用路径替换为网络地址
- 写完文章，全文复制粘贴到博客后台或通过API推送发布
这个流程的好处在于，图片处理和文字写作完全同步，不需要先整理图片列表再对照Markdown源码手工替换路径。对于高频写作者来说，每次配图节省一到两分钟，累积下来是笔不小的时间成本。
5. 常见问题与排查技巧实录
5.1 Gitee仓库与图片访问异常
问题表现：图片上传成功，但浏览器访问时提示404。
原因分析：这一类的根源基本都是URL路径不匹配。Gitee仓库文件有几种访问方式：raw开头的原始文件地址、blob开头的网页预览地址、以及Pages服务的静态页面地址。PicGo默认生成的可能是blob格式，但在网页里直接引用blob链接是拿不到图片内容的，必须用raw格式。
解决方案：在PicGo的URL路径设置里手动指定为https://gitee.com/用户名/仓库名/raw/分支名，保存后重新上传一张图片测试。
5.2 图片上传成功但Typora仍显示本地路径
问题表现：PicGo日志显示上传成功，Typora插入的图片路径仍然是C:/Users/xxx/...这样的本地地址。
原因分析：Typora的“插入图片时”选项可能没有正确设置为上传，或者上传服务选错了类型，又或者设置修改后没有重启Typora。
解决方案：回到Typora偏好设置，确认“插入图片时”选择的是“上传图片”，“上传服务”选择的是“PicGo(app)”且路径正确，然后重启Typora再测试。
5.3 换电脑或重装后如何快速迁移
对于经常在多个设备间切换的写作者，环境迁移有两种思路。第一种是把Typora的配置目录直接拷贝到新设备，适用于配置比较复杂的情况。第二种相对简单：在新设备上重装三个软件，然后按照本文第2、3、4节的步骤重新配置一遍，耗时大约十分钟。
我个人倾向于第二种，因为重装过程中可以顺手把软件升级到最新版，同时还能检查一下令牌是否需要更新。照片迁移的反倒是仓库里累积的图片文件，只要Gitee仓库不变，图片地址永久有效，文章内容无需任何修改。
5.4 仓库文件数量增长后的维护策略
用Gitee做图床时间长了，仓库里的图片会越来越多，文件名一多就容易混乱。我的做法是在PicGo的path参数里按年份或文章主题分类，比如img/2025/06/这种层级，配合Gitee仓库的目录管理，查找历史图片会轻松很多。
另外，有些图片上传后可能不再使用，建议定期整理仓库，删除失效文件。Gitee后台支持批量删除文件，操作起来不会太费时间。
6. 扩展场景与避坑经验
6.1 多博客平台图床复用
这套方案不只适用于静态博客。如果你同时维护多个平台的账号（比如博客、专栏、知识社区等），同样的图片地址可以通用，不需要重复上传。因为我用Typora写好后复制到任意平台，图片地址都是绝对URL，各家平台都能直接抓取显示。
注意一个例外：某些平台会在编辑器里强制将外部图片下载并转存到自己的服务器，遇到这种情况是平台规则所致，与图床方案无关。腾讯系平台大量采用这种策略，我在使用时直接把图片在编辑器内的临时域名替换成图床域名，也能解决。
6.2 图床方案的整体备份思路
这篇文章里面提到过多次“图片要备份”，具体怎么做最省事？我推荐一个组合拳方案：PicGo自带的日志会记录所有上传历史和图片地址，从日志里可以导出图片清单；Gitee仓库则支持一键下载打包，操作路径是仓库首页 → 克隆/下载 → 下载ZIP。每月执行一次下载备份，成本极低，但能避免极端情况下的数据丢失。
6.3 从免费图床到付费存储的平滑迁移
免费方案自然会担心稳定性，提前准备好Plan B是成熟的做法。如果后续博客流量变大、图片量增多，可以直接在PicGo里新增一个对象存储图床，然后在上传区点击“迁移”按钮，把Gitee上的图片全部转存到新图床。由于Markdown文章里的图片地址统一为图床URL格式，只需要全局替换一下域名前缀就能完成切换。
架构层面的迁移也没什么痛苦：所有文章本地都有Markdown源文件，Typora能直接打开编辑，图床只是存储层，换掉存储层不影响内容层。
7. 个人使用体会与建议
整套环境搭建完成后，我最大的感受是“写文章不再需要分心”。以前配图流程是先截图、存文件、打开博客编辑器、上传、复制链接、再插入Markdown，至少六个步骤。现在拖进Typora就完事，全程感知不到图床的存在，注意力完全集中在内容本身。
这种体验的提升不是单一工具带来的，而是组合的胜利。Typora优秀但缺少图床支持，PicGo功能强但缺少编辑器入口，Gitee速度快但缺少自动化能力，三者各取所长，弥补了彼此的短板。我始终相信，好的开发工具组合不是功能最全的，而是恰好能覆盖你的工作流，不多不少。
如果你还没搭好博客写作环境，这篇文章可以直接当操作手册用。如果已经搭好了，不妨试试把提交信息、URL路径这些细节调优一下，整个体验会再上一个台阶。最终目标是一致的：让写作回归写作，图片这种琐事交给工具链去处理就好。
