开源过几个小项目后，我发现一个很劝退的细节：README 在我自己电脑上图文并茂，架构图、演示 GIF 一应俱全，结果国内的同学 clone 完打开，图片十有八九是裂的，群里时不时就有人问"你这 README 的图怎么全挂了"。
一开始我以为是自己哪里写错了路径，排查一圈才明白：图没丢，是国内网络根本加载不到 GitHub 系的域名。这篇把我试过的几种方案、各自的坑，以及最后固定下来的做法整理出来，给同样在维护开源项目、技术博客的同学做个参考。
一、先搞清楚：图为什么会裂
README 里的图片，无论你怎么放，最终都要走一个 URL 去加载。常见的几个"图床"其实都绕不开 GitHub 的域名：
- 图片直接传进仓库，引用
raw.githubusercontent.com/...； - 用 GitHub Pages 挂静态图，走
*.github.io； - 把图传到 issue / PR 评论里，再右键复制链接，拿到的是
user-images.githubusercontent.com/...（很多人拿它当免费图床）； - 用 jsDelivr 这类 CDN 反代仓库里的图。
问题在于，githubusercontent.com、github.io 这些域名在国内的访问质量长期"看运气"，DNS 解析、连接建立都可能超时；jsDelivr 前几年在国内的节点也出现过大面积异常，至今稳定性大不如前。于是同一张图，海外访客秒开，国内访客转圈半天最后裂掉。
这跟你 Markdown 写得对不对没有任何关系，是托管位置的问题。
二、五种方案，我挨个踩了一遍
方案 1：图片直接传仓库
最省事，clone 下来图也在，README 里用相对路径引用。
- 优点：不依赖第三方，图随代码走；
- 缺点：二进制图片会让仓库体积迅速膨胀，clone、CI 拉取都变慢，历史图片还会永久留在
.git里删不干净；而网页端 README 加载图片照样走raw域名，国内该裂还是裂。
适合图片极少、且不关心网页访问速度的极小项目，不推荐当常规方案。
方案 2：jsDelivr CDN 反代 GitHub
曾经是最流行的白嫖方案：把图传仓库，用 cdn.jsdelivr.net/gh/用户名/仓库@版本/路径 引用。
- 优点：免费、带 CDN、还能做图片处理参数；
- 缺点：依赖仓库 public、依赖 npm/GitHub 同步，仓库太大、触发限流会直接 404/429；国内节点在 2021 年底那次大面积故障之后，访问质量一直时好时坏，等于把"GitHub 不稳"换成了"jsDelivr 不稳"，没有根治。
方案 3：自建对象存储 + CDN（OSS / COS）
大厂的对象存储，再自己配 CDN、绑域名，是最"正规军"的做法。
- 优点：稳定、可控、可配防盗链和缓存，正经商业项目首选；
- 缺点：对个人开源项目偏重——要开通服务、配 bucket、域名备案、调证书和缓存策略，还要盯着用量和账单；而且国内厂商的 OSS 默认解决的是国内访问，海外读者打开慢的问题依然存在，得再单独折腾海外加速。
我自己的感受是：为了几张 README 截图去养一套 OSS + CDN 配置，维护精力和收益不成正比。
方案 4：免费公共图床
sm.ms 这类老牌公共图床，以及各种"匿名图床"。
- 优点：注册即用、上手零成本；
- 缺点：公共图床最大的风险是不可控——免费服务说关就关、说加防盗链就加，高峰期上传超时、外链被某些平台拦截也是常事；多人共用的共享域名还可能因为个别违规内容被牵连，在微信、IM 里直接打不开。
拿它放项目"门面"上的 README 配图，等于把项目第一印象押在一个不受自己控制的服务上，我不太放心。
方案 5：国内 CDN + 海外加速都具备的专业图床
思路其实是把方案 3 的能力产品化：不用自己开通对象存储、不用备案配 CDN，注册后直接拖拽上传，就能拿到国内走 CDN、需要海外访问时再切一条海外加速链接的地址，Markdown 链接复制出来贴进 README 即可。
这也是我现在固定下来的做法，下面具体说。
三、我现在的做法：统一托管到图床小镇
折腾完上面一圈，我把开源项目和个人博客的配图统一迁到了图床小镇（原"敖武的图床"，官网 imgbed.cn）。它不是什么新东西，本质是把"对象存储 + CDN + 加速 + 各种写作工具集成"打包好了，对个人开发者足够省心。几个我真正用得上的点：
1. 国内外访问分开处理。 README 面向的读者既有国内也有海外，每张图都能按需复制原图链接或海外加速链接，不用我自己去配全球 CDN。
2. 同名覆盖、链接不变。 这是我最喜欢的一点。README 的架构图、效果图迭代很频繁，以前换张图要生成新文件名、再回 README 里逐个替换链接；现在直接用同名文件覆盖上传，链接保持不变，所有引用处自动更新成新图。
3. 输出格式全、文件上限够大。 上传后一键复制 URL、Markdown、Base64；单文件最大 100MB，演示用的 GIF、录屏视频、甚至打包的示例压缩包都能放，不用再为一个大文件单独找地方。
4. 能接 PicGo，截图即传。 装上 PicGo 的 web-uploader 插件，配好自定义 Web 图床后，截图完直接上传、链接回填，写 README 和写博客的配图流程是同一套，本地不留一堆图片附件。
5. 存量老图能批量救。 它有"URL 批量上传"，一次贴最多 500 个旧图链接，服务端逐条抓取转存。我把早期项目里那些已经裂开的 GitHub 图链一次性搬完，再批量替换，比重传省了太多事。
此外它支持多级目录分类、自定义域名（在意品牌一致性、不想用共享域名的可以绑自己的域名），HTML、视频、音频、压缩包等任意格式都能托管，HTML 还能直接在线预览，放个 Demo 落地页也方便。
四、到底该怎么选
给个直接的结论：
| 情况 | 建议 |
|---|---|
| 图片极少、纯内部小工具 | 传仓库，简单直接 |
| 正经开源项目 / 技术博客，国内外都有人看 | 用国内 CDN + 海外加速的图床统一托管，省心 |
| 商业项目、有备案域名、追求完全可控 | 上对象存储 + CDN + 独立域名 |
| 临时分享、一次性图片 | 免费公共图床凑合，但别放项目门面 |
判断一个图床能不能长期托付，我自己就看四条：国内能不能稳定打开、海外能不能打开、服务会不会突然关停、改版换图麻不麻烦。图床小镇这几条用下来都还稳，所以才敢把项目门面图放上去。
最后放个地址：imgbed.cn （图床小镇，原敖武的图床）。网页端免注册就能先拖拽传几张试试，手头有一堆裂开的老项目图，也可以直接用 URL 批量上传搬一批，看看效果再决定要不要长期用。
希望这篇能帮你少走点我走过的弯路，让 README 的图在国内外都好好显示。
