★ FEATURED ARTICLE 1. 方案选型为什么是Typora、PicGo与Gitee1.1 博客图片管理的痛点写博客的人几乎都经历过这样的尴尬本地笔记里插图一切正常文章一发布到博客平台图片全部变成裂开的图标或者加载慢得像在等火车。归根结底是图片的存储位置出了问题——本地路径只能自己看网络路径如果选错了服务商要么收费要么龟速。图片管理这件事表面上是“存哪儿”的问题实际牵扯到三个层面图片能不能被公网访问、访问速度快不快、成本能不能接受。早期的做法是把图片传到博客平台自身的服务器但换平台就得重新传一遍图片域名还被平台锁死。后来有人用对象存储稳定是稳定但流量一上去账单也上去了个人博客那点流量又用不满怎么看都亏。我的选择标准很简单免费、稳定、国内访问快、能长期持有。三个条件筛下来剩下的方案其实不多。1.2 三件套的分工与组合逻辑Typora负责写PicGo负责传Gitee负责存。这三者各有各的专长拼在一起刚好形成一条完整的链路Typora是一款本地Markdown编辑器所见即所得写文档时图片直接拖进编辑器就能看到效果不需要在源码和预览之间来回切。它自带了“上传图片”功能可以把图片发送到外部工具处理这种设计为图床方案留好了接口。PicGo是专门处理图片上传的桌面工具支持多种图床自带压缩、重命名、日志等功能稳定且开源。它的核心价值是把“上传图片”这件事从手动操作变成自动化。Gitee是国内的代码托管平台支持创建仓库存放静态文件仓库里的图片可以通过固定链接直接访问。虽然它的定位不是图床但个人博客的图片量完全够用而且国内服务器的访问速度是明显优势。这个组合的巧妙之处在于每个工具只做自己最擅长的事彼此之间通过标准接口协作。Typora不需要知道图片传到了哪里PicGo不需要关心文章内容Gitee只负责把文件存好并提供访问链接三者零耦合任何一环都能单独替换。1.3 潜在替代方案对比这里我把几种常用方案放在一起做了个对照方便你判断自己的场景适合哪种方案成本国内访问速度稳定性维护复杂度Gitee图床免费快中等需注意仓库规则低对象存储按量付费低快高低国外代码托管平台免费慢或极不稳定中等低博客平台自带图库免费取决于平台高高换平台需迁移如果你只写技术博客且图片量不大Gitee图床是我目前用下来性价比最高的方案。当然对象存储的稳定性天花板更高这一点我在文末还会聊到。2. 环境准备与基础配置2.1 安装Typora与PicGoTypora的安装没什么特殊之处直接去官网下载对应系统的安装包一路默认选项装完即可。这里提醒一句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路径这些细节调优一下整个体验会再上一个台阶。最终目标是一致的让写作回归写作图片这种琐事交给工具链去处理就好。
阅读完成 · 觉得有帮助？
