企业官网建设流程全解析

经常用Markdown码字的人应该都有过这种体验：文章写到一半截了张图，然后打开浏览器、登录图床、拖进图片、等上传、复制链接、切回编辑器、把链接粘到图片语法里……整套动作做下来，写作的节奏全断了。我折腾过几套方案之后，最后稳定下来的组合就是 Typora + PicGo + Gitee：Typora负责写，PicGo负责传，Gitee负责存图并回传外链。这篇文章就把这套环境的完整搭建过程、每个参数怎么填、以及我实测中踩过的坑一次性说清楚，尽量做到你照着操作就能跑通。

适合谁看？如果你用的是 Hugo、Hexo 这类静态博客，或者经常往公众号、知乎这类平台投稿，只要文章里图片超过三张，这套配置就能省下大量重复劳动。它对你现有写作习惯几乎零侵入，装好之后，你过去怎么在 Typora 里写文章，现在还怎么写，只是图片处理这件事从手动变成了全自动。

1. 三个工具各管一段：这套组合到底解决什么问题

很多人第一次听说“图床”这个词会觉得有点高深，其实理解起来非常简单：图床就是一个存放图片、并且能通过 URL 让任何人在线访问的地方。Typora 是本地写 Markdown 的编辑器，PicGo 是负责把图片上传到图床的客户端，Gitee 则是那个“存图片的仓库”。三者串起来，就形成了一条完整的图片自动化链路。

1.1 从手动传图到一键上传，工作流差多少

我先画一下传统的、大多数人都在用的手动流程，你看看是不是很眼熟：

对比下来，最大的差异不是“省了十秒钟”，而是写作过程中的注意力和节奏没有被频繁打断。手动传图最烦的不是操作本身，而是每次都要从“写文章”的状态切换成“处理工具”的状态。一旦切出去，回来时往往要想半天刚才写到哪里了。

1.2 为什么是 Gitee 而不是其他图床

图床可选的方案其实非常多：云厂商的对象存储、第三方免费图床、GitHub 仓库等等。我最终把 Gitee 留下来，理由很朴素。

第一，直连速度。博客读者打开文章时，图片加载快不快直接决定阅读体验。Gitee 在这些年里的使用感受，对我来说基本是“秒开”。第二，免费且容量足以支撑个人博客的图片量。第三，它是 Git 仓库，图片的历史版本可以被追踪，误删了还有机会从提交记录里找回来。第四，稳定性比个人维护的第三方图床强得多。很多第三方免费图床是个人开发者用爱发电，今天能用、明天可能就 404 了，把自己的图片放在代码托管仓库里，至少可控很多。

不想用本地相对路径，是因为文章一换机器、一换目录就会全部裂图；不想用 GitHub，是因为作为图床场景，它的图片加载在不少网络环境下不够稳定，读者打开文章半天刷不出图很影响体验；直接买云厂商 OSS 当然可以，但对个人博客来说又是一笔持续开销。综合下来，Gitee 是性价比最均衡的选项。

当然，Gitee 做图床也有它自己的限制，比如免费仓库容量有上限、仓库一旦公开所有人都能看，这些我在第 5 章会专门展开。

2. 先把图片仓库腾出来：Gitee 端需要做的几件事

这套方案里，Gitee 是被调用的那一端，所以我们要先把它准备好。这个准备过程分为两步：建一个公开的图片仓库，再生成一把允许 PicGo 往仓库里写文件的“钥匙”。

2.1 创建专用于存放博客图片的仓库

打开 Gitee，注册并登录后，在页面右上角的“+”下拉菜单里选择“新建仓库”。仓库信息按照下面这组建议填：

• 仓库名称：用blog-images或images这类一眼就能看出用途的英文名，因为仓库名会直接出现在图片链接里，太长太乱，后面的 URL 会非常难维护。
• 归属：选择你的个人账号。
• 路径：一般会自动跟随仓库名生成，不用额外改。
• 仓库介绍：可填可不填，不填不影响使用。

最关键的一步是“公开 / 私有”的选择。图床仓库一定要选公开。图片链接要被读者的浏览器直接访问，私有仓库的图片 URL 需要认证凭证，不可能塞进文章里给别人用。只要遵守一条纪律——“这个仓库里只放图片，不夹带任何隐私内容”，公开仓库就没有额外的安全隐患。

仓库创建完成后，有两点信息要立刻记下来：你的用户名（个人空间地址那段标识）、仓库名，以及仓库当前的分支名。分支名很容易被忽略，因为不同时期创建的仓库默认分支可能不同，有的是master，有的是main。PicGo 配置里会精确用到这个分支名，填错了后面上传就会出问题。

2.2 生成私人令牌（Token）

令牌是给 PicGo 上传图片用的凭据。生成路径是：点头像进入“设置”，在左侧菜单找到“安全设置”下的“私人令牌”，点击“生成新令牌”。

生成的时候会让你填一个描述，我一般写picgo-image-upload，方便以后在令牌列表里一眼认出这是给谁用的。接下来是权限范围勾选，这一步非常重要：只勾选中和仓库项目相关的权限，比如projects，不要图省事把所有权限全部勾上。授权范围越窄，令牌泄露时的损失就越小。

提交后，页面会显示一串很长的字符，这就是 Token。它这次生成后就再也看不到了，刷新页面会消失，所以一定要当场复制并保存在安全的位置。Token 本质上就是一把能往你仓库里写文件的钥匙，谁拿到它就能操作你的仓库。不要把它提交到任何公开的仓库、博客配置或者云端笔记里，尤其当你的电脑需要和别人共用时，更要小心。

2.3 顺手做一次本地备份

仓库建好、Token 拿到之后，我建议立刻把仓库克隆到本地一份。在终端里运行：

git clone https://gitee.com/你的用户名/仓库名.git

这一步不是必须的，但非常推荐。图床仓库说到底是个 Git 仓库，之后每次通过 PicGo 上传图片，远端都会多出新的提交。定期在本地执行：

git pull

就能把远端图片全部同步回电脑里。图床仓库没有代码合并冲突的问题，因为只有上传动作，不存在多人改同一批文件的情况，拉取回来非常安全。这是成本极低、却能在关键时刻救命的备份习惯。

3. PicGo 侧配置：把图片投递到 Gitee 仓库的关键参数

Gitee 端准备好之后，接下来配置上传工具 PicGo。这部分是整个流程里最容易被参数坑到的地方，只要有一个字段填错，上传就会失败。建议耐心把每个参数的含义弄清楚，后面就可以一劳永逸。

3.1 安装 PicGo 与 Gitee 上传插件

PicGo 的安装本身不复杂，到它的官方发布页下载对应系统的安装包即可，macOS 和 Windows 都有图形化版本。这里有一个老生常谈的注意点：安装目录不要带中文、不要带空格。我早期吃过这个亏，把程序装到了带中文的路径下，Gitee 插件怎么都装不进去，换了纯英文目录后立即正常。这类工具类软件对路径字符很敏感，能不折腾就不折腾。

安装完成后启动 PicGo，它会驻留在系统托盘里。主界面有“上传区”“相册”“图床设置”等几个功能区。先别急着拖图，去“插件设置”页面，在搜索框里输入gitee，找到对应的 Gitee 上传插件（插件名一般是gitee-uploader）并点击安装。插件的安装过程本质上是把一段扩展程序注册到 PicGo 内部，如果长时间没有反应，优先检查网络是否顺畅、安装目录是否纯英文。具体原因可以从 PicGo 的日志面板里看到。

安装成功之后，左侧“图床设置”里会多出一个 Gitee 的配置入口，点进去就是我们要填的一整套参数。

3.2 图床参数逐项说明

这里的参数是整个配置的核心，我把每一项的含义和容易踩的坑列成了一张表：

repo填错是最常见的。注意要填“用户名 / 仓库名”的完整形式，而不是只有仓库名。branch要严格对齐仓库当前分支，新建仓库通常是master，但如果你不确定，就去 Gitee 仓库页面的文件列表上方看分支名。token粘贴时一定要选中完整字符串，不要多选前后空白内容。

customPath和customUrl是进阶项。我习惯按年月归档，在customPath里填2025/06，图片最终就会落在img/2025/06/文件名.png，仓库结构按月份整理得清清楚楚。customUrl对普通用户建议留空，Gitee 的 raw 链接格式本身非常固定，插件会按照仓库、分支、路径的顺序自动拼接出地址。

3.3 本地上传试验：确认链路真的通

配置完成后，回到 PicGo 的“上传区”，拖一张测试图片进去。正常情况下几秒钟后，通知区域会出现上传成功的提示，并且图片 URL 已经自动复制到了剪贴板。打开浏览器访问这个 URL，如果图片能直接显示，就说明链路完全跑通。

如果上传失败，主界面会给出红色错误提示。这时候不要乱猜，直接打开 PicGo 的日志面板，日志里通常会写明具体的 HTTP 状态码或错误原因。大致方向：

• 401/403：认证层问题，朝 token 查；
• 404：仓库名、分支名或路径填错，图片被投递到了不存在的地址。

上传成功后，去 Gitee 仓库页面看一眼目录结构，确认图片确实落在预期位置。这一步验证虽然多花两分钟，但能提前把配置层面的低级错误全部暴露出来。

4. Typora 配置：写文章时图片自动走图床

前面三步做好，只是完成了“手动传图”环节的自动化。最后一步是把 Typora 和 PicGo 对接起来，让图片在编辑器里粘贴的瞬间就自动上传。

4.1 图像偏好设置与上传服务选择

打开 Typora 的偏好设置：macOS 按Cmd+,，Windows 按Ctrl+,，然后选择“图像”分类。这里有三个关键操作：

第一，在“上传服务”下拉框里选择PicGo(app)。Typora 支持的上传服务不少，有 PicGo(app)、PicGo-Core(command)、Custom Command 等，对于我们已经装好 PicGo 桌面的情况，选 PicGo(app) 最直接，它会把图片发给正在运行的 PicGo 客户端处理。

第二，指定 PicGo 应用的路径。macOS 通常要定位到PicGo.app，Windows 定位到PicGo.exe。路径选错的话，点击测试时 Typora 会提示找不到应用。

第三，配置完成后点击“验证图片上传”按钮。Typora 会生成一张测试图片，完整走一遍“本地 → PicGo → Gitee → 返回 URL”的流程，并给出成功或失败的明确提示。这个验证动作千万别跳过，它能帮你提前发现前面所有步骤里隐藏的问题。

4.2 设置插入图片时的自动上传行为

Typora 的图像设置里，还有一些和“插入图片时”相关的行为选项，值得专门调整。

如果你希望粘贴一张图就立刻自动上传，可以把“插入本地图片时”的行为设为“上传图片”。这样每次截图后在编辑器里直接粘贴，Typora 会自动把图片交给 PicGo，本地不会残留大文件副本。

如果你写长文时更希望不被打断，可以暂时不开启自动上传，等全文定稿后，在文本编辑区点击右键或通过“图片工具”菜单找到“上传所有本地图片”，Typora 会扫描当前文档里所有引用本地文件的图片，批量上传，并把 Markdown 里的本地路径全部替换为 Gitee 的 URL。这个批量功能是我日常使用频率最高的入口之一。

另外建议把“复制图片到 assets 目录”之类的本地副本选项一并开启。自动上传负责生成远端链接，本地副本负责在你的电脑上留底。图床哪天真出问题，你本地至少还保留着一份完整的原始图片，不会落得一无所有。

4.3 实测一次完整的写作上传流程

配置完成后的实际体验是这样的：在 Typora 里直接粘贴一张截图，编辑器立即显示图片预览，图片位置短暂出现“正在上传”的状态，一两秒后，查看 Markdown 源码，原本的临时路径已经被替换成了https://gitee.com/...的完整 URL。整个过程你不需要切出编辑器。

等整篇文章写完后，把内容复制到博客平台，图片直接就能显示。对于支持 Markdown 上传的平台，甚至都不需要再单独插图。

如果遇到图片插入后迟迟没有变成 URL，优先按这三点排查：PicGo 有没有启动、Typora 的上传服务有没有选对、插入图片时的行为有没有被设成“无”。绝大多数情况都出在这三个地方。

5. 实测中踩过的坑和对应解法

这套方案虽然成熟，但并不是零坑。接下来的内容是我不愿意删掉的重要部分。每一个坑都是实际跑过的，有些反直觉，有些纯属手误，但结果都一样——图片传不上去也打不开。

5.1 图片打不开：仓库可见性和分支名的锅

最经典的翻车现场是：PicGo 提示上传成功，相册里也有记录，但把 URL 丢进浏览器，要么 404，要么提示仓库不存在。

排查顺序固定为三层。第一层，仓库是否公开。私有仓库的文件 URL 外人无法访问，图床场景下仓库必须公开。第二层，raw 路径里的分支名是否和仓库实际分支一致。很多 Gitee 仓库默认分支是master，如果你在 PicGo 里填了main，上传动作本身可能不会立刻报错，但生成的链接指向的路径并不存在，自然 404。第三层，路径大小写是否匹配。Gitee 对路径大小写敏感，仓库里实际是Img，URL 里写成img就访问失败。

还有一个容易被忽略的致命操作：仓库创建后不要频繁改名、改分支。每次改动，所有引用这个仓库图片的文章都会集体裂图。仓库一旦开始做图床，就让它安安静静保持原样。

5.2 上传报错 401 / 403：认证问题的高概率原因

401 Unauthorized和403 Forbidden都属于认证层错误，查 token 方向基本不会错。常见原因有三种：Token 复制不全，或复制时带了引号、换行符；生成 Token 时没有勾选仓库写入相关权限；Token 被人为吊销过，但 PicGo 里还在用旧值。

解法很简单：重新生成一个 Token，只勾选projects权限，粘贴时确认首尾干净，保存后再传一张图验证。另外要注意，Gitee 图床插件接收的就是纯令牌串，不要在前面加任何修饰前缀。如果你之前用过某些 API 工具，习惯在 Token 前面加认证类型标识，粘进来反而会导致认证失败。

5.3 插件安装异常或上传时环境报错

gitee-uploader 插件安装卡住，或者安装成功后上传日志里出现依赖缺失类的报错，通常和 PicGo 本身的安装环境有关。第一步检查安装路径，中文路径或者带空格路径会让插件在加载资源时找不到正确位置，重装到纯英文路径可以解决大部分问题。第二步检查 PicGo 版本，绿色版或过分古老的版本可能缺少某些组件，换官方最新版本通常就好。第三步看日志，日志面板会给出具体错误信息，不要怕看，这些技术细节反而能帮你快速定位问题。

这类环境问题看起来像玄学，但思路是固定的：先看日志，再重装，最后考虑版本兼容。按这个顺序排查，基本都能在十分钟内解决。

5.4 仓库容量与图片数量失控

Gitee 免费仓库有容量限制，个人博客图片如果不压一压，两三年后很容易接近上限。几乎每个长期使用这套方案的人最后都会面临一次“图片太多”的清理。提前做好下面三件事，能推迟这一天的到来：

第一，上传前压缩图片，别把 2MB 的原始截图原样丢上去。第二，定期把仓库克隆回本地，删除已不再引用的图片，再把删除操作推送到远端。第三，按年份拆仓库，比如2025-images、2026-images，单仓库压力小，归档也更方便。

这里把 Gitee 图床的另一个特性一并说了：如果你在某个博客平台看到图片反复加载不出来，但浏览器直接打开 URL 却是好的，那是目标平台的外链过滤或防盗链策略在起作用。别想着和平台硬刚，要么换平台支持的图片托管方式，要么调整图片引用的上下文，绕开触发条件。

6. 让这套环境更耐用的三个补充建议

搭建完成只是第一步，真正让这套环境长期好用，还取决于日常使用习惯。这里分享三个我实践后觉得很有用的补充建议。

6.1 图片压缩与格式取舍

图床最怕的不是图片数量多，而是单张图片体积大。一张截图动辄两三 MB，传上去很快，但读者打开文章时要拉取的流量也很大。我的经验是，博客配图单张控制在 100KB 到 300KB 之间是最舒服的区间。

截图类图片建议保留 PNG 格式，它对大面积同色区域的压缩效果很好；照片类图片再考虑转成 JPG 或 WebP。如果觉得手动调整太麻烦，可以利用截图工具的自动压缩能力，或者在上传前先经过一次宽度缩放。不要小看这一步，它直接关系到仓库容量的耐用性和读者端的加载速度。

6.2 给图片定一套命名规范

文件名看似小事，实际影响长期体验。中文文件名或带空格的文件名，上传之后 URL 会变成一长串百分号转义，在浏览器地址栏里很难看，在 Markdown 源码里也影响阅读。

我的规范是“日期 + 短横线 + 关键词”，比如20250614-typora-upload.png。这一套命名规则的好处是，一年后回到图床仓库，看到文件名就知道图片属于哪篇文章、大概什么时候传的，删除或复用都非常直观。养成这个习惯的成本约等于零，但收益在图片数量超过一千张之后会非常明显。

6.3 备份与多图床冗余

图床不是 100% 不会出问题的服务，所以要给自己留好退路。第一步是本地备份，图床仓库本身就是 Git 仓库，每周git pull一次，本地就会始终保留一份完整图片副本。Typora 里如果开启了复制到 assets 目录，文章所在目录下也会自然积累一套原图。第二步是多图床冗余，在 PicGo 里额外配置一个备用图床，日常文章继续走 Gitee，一旦 Gitee 侧出现临时维护或故障，切换备用图床重新上传关键图片即可。不要把所有图片都放在一个篮子里，这个道理很简单，但真正坚持做到的人并不多。

这套环境我实际用了小半年，最直观的变化不是“一次省了几秒钟”，而是写作过程中的注意力不再被打断。以前每截一张图就要切一次窗口，写长文有一种明显的割裂感；现在图片上传完全发生在后台，我甚至更愿意配图了，因为成本几乎为零，多一张图对读者多少算一份友好。

最后分享一个个人习惯：写超过一万字的长文时，我会把 Typora 的图像行为从“自动上传”临时改成“本地保存”，等全文定稿之后再统一用“上传所有本地图片”批量处理。这样写作过程中网络波动不会影响节奏，定稿后一次性上传，即使有哪张图失败，排查范围也足够集中。希望这套配置能帮你也把注意力从图片琐事里解放出来，专心写真正重要的内容。