1. 为什么本地图片换个机器就裂md文件根本不存图先说个真实场景。我自己写技术文档有个习惯全部用md文件管理本地用Typora写配一套自己的目录结构图片都丢在附件文件夹里。有一次写完一份挺详细的方案打包发给同事对方回了一句文档内容很好就是所有截图都是裂的。我第一反应是打包漏了图片文件夹重新打了个压缩包对方说还是裂的。后来我远程一看才发现问题不在打包而是我写文章的时候图片的引入路径是类似于这种相对路径压缩包解开之后目录结构变了路径对不上图片自然就加载不出来。这个经历几乎是每个用md写文档的人都会撞上的墙。根源在于md文件本身的定位它是一个纯文本文件只描述内容结构和格式图片、附件这类二进制资源根本不会内嵌到md文件里。md的图片语法重点在那个路径上——它只是告诉渲染器这里应该有一张图去哪里找图本身并不在文件里。1.1 md是纯文本图片只是路径引用很多人第一次接触md时容易把它类比成Word。Word里插一张图图片数据是直接写进docx文件的你把文档发给任何人图片都跟着走。但md不是这样它本质上就是一堆带标记的普通文字![]()只是文字的一部分。渲染器拿到这段标记之后需要根据路径去指定的位置加载图片。这个路径可以是三种绝对本地路径比如只有你本机能打开。相对本地路径比如压缩包结构不变才能打开变了就裂。网络URL比如只要能上网就能打开。前两种本地路径带来的问题就是为什么md文件传给别人图片就不显示。因为你的图片是存储在你自己磁盘上的别人机器上根本没有这个文件。第三种网络URL是解决这个问题的标准思路而把本地图片变成网络URL的过程就是俗称的图床配置。1.2 本地链接与网络链接一个直观对比为了把问题讲透我用一个表格来说明本地路径和网络URL的差异对比维度本地路径网络URL图片数据存在哪自己电脑磁盘远端服务器发给别人能否显示不能对方机器没这张图能对方通过网络加载压缩包是否必须包含图片目录必须且路径完全一致不需要md文件单文件即可是否能跨平台渲染不行行只要有网络隐私风险低需要特别注意访问权限所以整个问题的核心矛盾就一句话md是纯文本文档靠路径引用图片要让任何人在任何地方打开都正常显示路径必须是公共网络上可达的URL。1.3 两条路压缩包方案与图床方案解决图片随doc走的问题最简单的应急办法是把整个目录打包发给对方目录结构保持原样。但这种方式有几个硬伤一是跨平台时Windows和macOS对路径大小写、斜杠方向的容忍度不同很容易出岔子二是如果文档上百张图压缩包动辄几十上百MB传输效率很低三是别人如果要把内容转发到网页、公众号或者在线笔记平台本地路径的图片一律显示不了。于是就有了图床这种方案。所谓图床本质上就是一个专门存放图片文件的服务器你把自己md里的图片上传上去得到一个公开的URL然后把md里的本地路径替换成这个网络URL。这样发出去的单文件md无论谁打开都能通过网络把图片加载出来。这也是我最终的归宿折腾过几套方案之后目前长期用的是腾讯云COS配合PicGo和Typora后面我会把配置链路完整走一遍。2. 图床选型大厂对象存储为什么是稳定基线图床听起来很专业其实可选的范围很广。有免费的公共图床站点有GitHub仓库当图床的野路子也有自建服务器或者云开发平台的方案。但如果你问我长期写文档、图片量不小、又不想老担心链接失效我的建议很直接优先选大厂的对象存储服务比如阿里云OSS、腾讯云COS、七牛云Kodo这类。2.1 常见选择的横向对比我用过不少方案列个表把主观感受写出来给还没入门的读者一个参考方案成本稳定性访问速度配置复杂度适合场景公共图床站如SM.MS免费或很便宜一般有跑路风险一般低随手分享、个人博客少量图GitHub仓库当图床免费网络环境不稳定时访问慢国内一般中技术文档、开源项目配图个人服务器Nginx服务器费用取决于服务器取决于服务器位置高有服务器且懂运维的人大厂对象存储COS/OSS按量计费成本极低高好可配CDN中长期稳定使用推荐首选2.2 为什么我最后锚定在大厂对象存储先说成本。很多人一听云服务就觉得贵其实对象存储的定价逻辑是按量计费而且存储单价极低。以腾讯云COS为例标准存储目前大约一毛多钱一个G一个月流量费也是按G计。一个纯文档写手一个月图片量大概在几十MB到几百MB算下来每个月费用常常在几毛钱到几块钱之间几乎可以忽略。真正要注意的是避免浪费和欠费风险这点我后面会提到。再说稳定性。文档图片链接的生命周期按年来算你两年前写的一篇技术文章两年后还有人点开看图片必须还能加载。公共图床站跑路、停止服务的案例太多了免费的东西最大的风险不是不好用而是某天突然不可用了所有引用这个图床的文档全部裂图那等于你所有历史文档都陪葬。GitHub图床也有类似风险——仓库被清了、分支被删了或者网络环境出现波动图片就加载不出来。对象存储是付费服务有商业合同约束稳定性完全是另一个量级。最后说生态。大厂的对象存储基本都有配套的SDK、命令行工具、开源上传器集成方案比如PicGo就是专门干这个的配置一次就能在编辑器里拖拽上传。而且可以额外加CDN加速图片访问速度有保障。这种一条龙的体验是小众公共图床给不了的。2.3 一个容易被忽略的坑欠费与防盗链对象存储按量计费的模式有个隐形风险——盗刷和欠费。如果存储桶权限设置成公开读、并且没有配置防盗链你的图片URL一旦被人拿到可能被恶意引用造成额外的流量费用。我自己就收到过一次COS欠费短信查下来是某篇文章里的图片被一个爬虫站点盗链了跑了几G流量虽然金额不大但那种突然被通知欠费的体验很糟糕。所以配置图床时两个事情不能偷懒一是权限要设置成公有读私有写读公开、写私有二是必须把防盗链的Referer白名单打开。后面配置章节里我会把操作细节展开这里先记住结论就行。3. 手把手配置腾讯云COS图床从零开始到第一张外链图片选定大厂对象存储之后我用腾讯云COS作为例子把完整流程走一遍。之所以选COS没有别的玄学是因为我自己的域名和CDN都在腾讯云体系里管理上方便一点。如果你用的是阿里云OSS、华为云OBS操作逻辑大同小异理解原理之后换平台只是换个控制台入口的事。3.1 开通COS并创建存储桶第一步登录腾讯云控制台搜索对象存储COS如果没有开通会提示你开通服务。开通本身不需要付费按量计费意味着用多少算多少没有包月包年这种购买门槛。接下来创建存储桶Bucket。存储桶就是存放图片文件的大盒子一个账号下可以建很多个。创建时字段不多但是有一个必须想清楚存储桶的地域Region选择。这个地域决定了你的图片服务器放在哪个机房里直接影响到你的上传速度和读者访问速度。如果你面向的读者主要在国内选上海、广州、北京这些节点都行如果你长期面向海外读者选新加坡、法兰克福这类海外地域会更合适。地域创建之后不能改至少不能直接改所以一开始就要想好。创建界面里的访问权限选项默认是私有读写这个保持默认即可具体放开的动作我们后面通过桶策略来做不在创建这步直接改成公有读。存储桶名字也起得有意义一点比如md-images-1250000000因为这里的名字会出现在你的图片URL前缀里。3.2 读写权限与防盗链配置让图片公开可读但不任人盗用存储桶创建好之后默认私有读写意味着你上传的图片只能你自己通过凭据访问。要让别人看得到需要把读权限放开也就是设置成公有读私有写。操作路径进入存储桶 - 权限管理 - 存储桶访问权限 - 将公有读私有写勾选上。这一步做完你传上去的图片就有了公开的访问URL任何人拿到URL都能加载。但公开读同时意味着任何人拿到URL都能访问如果 URL 被人爬走了流量就不可控。所以紧接着要做两件防御性配置。第一设置防盗链。在权限管理里找到防盗链设置开启防盗链然后配置Referer白名单。比如你的文档主要发在自建博客就把你的博客域名加进去如果md文件发给同事、发到企业微信、钉钉、飞书这些平台这些平台的来源域名也加入白名单。这里有个细节有些在线文档平台直接把图片通过特殊User-Agent的爬虫拉取到自己的CDN里Referer可能是空的或者不固定的所以白名单别设置得太死否则可能误伤正常使用场景。我的经验是开启防盗链但把空Referer允许访问这个选项也打开因为很多博客、邮箱、聊天工具加载图片时Referer为空关掉会导致图片在这些场景下裂开。第二设置跨域规则。如果你的图片之后要嵌入到网页里用Canvas处理或者将来给在线文档做水印功能CORS跨域资源共享规则就会用到。这个配置在安全管理或跨域访问CORS设置里添加一条规则AllowedOrigin填*AllowedMethod选上GET、HEAD、POST等AllowedHeader填*。多数人用图床不会用到CORS但既然来了控制台顺手配一下不亏省得以后用到时被莫名的跨域报错卡住。3.3 自定义域名与CDN加速把默认URL变成自己的稳定地址存储桶默认会生成一个访问域名形如md-images-1250000000.cos.ap-shanghai.myqcloud.com。这个域名是可用的但有两个问题一是太长复制粘贴容易出错二是这个默认域名在某些写博客的渲染环境下容易被拼错或者被某些平台的链接检测拦掉。所以强烈建议绑定一个自己的自定义域名到COS上。操作路径存储桶 - 域名管理 - 自定义域名 - 绑定域名。需要准备的是一张已经备案的域名这是国内云服务商的硬性要求然后在域名解析控制台添加一条CNAME记录指向COS给你的默认域名。绑定完成后你的图片URL就变成了https://img.example.com/图片文件名简洁又好记。如果想要图片访问速度再上一个台阶可以在自定义域名下再勾选开启CDN加速配置CDN域名并回源到存储桶。CDN会把图片缓存到边缘节点上用户访问时从最近的节点取数据速度会明显提升。对于博客方的长期读者这个收益比较主观但如果你写的是带大量截图的技术教程读者翻页多、图片多CDN加速给体验带来的提升是实打实的。3.4 用上传工具传第一张图验证URL可用配置完成之后先不急着搞自动化手动往存储桶里传一张测试图片。两种方式一种是在控制台直接上传文件列表里点击上传文件选择本机图片另一种是用命令行工具coscli输入密钥之后批量上传。控制台适合偶尔用命令行适合初始化大批量图片时用。上传成功后在对象列表里点击图片能看到一个对象属性里面就有图片的访问URL。用浏览器打开这个URL如果能直接显示出图片说明你的存储桶权限、域名绑定、防盗链配置都到位了。如果打开是Access Denied多半是权限设置没生效或者防盗链把空Referer拦掉了回头检查这两处。4. PicGo Typora把图床上传变成肌肉记忆到这一步我们已经有了一个能用的图床。但每次都打开网页控制台手动上传图片、再手动复制URL、再粘贴到md文件里效率太低。真正舒服的用法是把图床上传集成到写作流程里让截图 - 自动上传 - 自动生成md图片链接一气呵成。这一步我配合用的是PicGo和Typora。4.1 PicGo的COS图床配置PicGo是一个开源的图床管理工具支持几乎主流的所有图床服务包括腾讯云COS、阿里云OSS、七牛云、GitHub等。它的工作方式是你配置好一个图床之后把图片文件拖进PicGo窗口或者截图后直接按快捷键图片就会自动上传上传完成后自动把一个URL复制到你的剪贴板里。配置步骤下载安装PicGo打开图床设置选择腾讯云COS。需要填的参数有几个SecretId和SecretKey这个在腾讯云控制台的访问管理 - API密钥管理里获取。注意SecretKey安全性极高不要泄露不要在公开截图里暴露。Bucket填存储桶名称例如md-images-1250000000注意不带后面的.cos.region.myqcloud.com后缀。AppId就是存储桶名称里的那串数字例如1250000000。地域 Region填ap-shanghai这种。注意务必和创建存储桶时选择的地区一致。自定义域名如果你绑定了自己的域名填在这里生成的URL会用你自定义的那个地址。填完之后点击设为默认然后打开PicGo主界面拖进一张图测试。上传成功后在相册里能看到图片记录点复制链接把链接粘贴到浏览器里确认可访问。到这一步图床的单次上传已经全自动了。4.2 Typora集成PicGoTypora是目前我用下来对md体验最好的本地编辑器它支持直接调用外部图床工具配合PicGo能做到粘贴图片即可自动上传。在Typora的偏好设置里找到图像模块做三件事插入图片时选择上传图片这样粘贴图片时自动走图床上传流程。上传服务选择PicGo(app)然后选择PicGo可执行文件的路径。顺便勾选对本地位置的图片应用相同规则这样手动拖入本地图片时也会自动上传而不是保存成本地引用。配置完成后随便打开一个md文档截图然后直接粘贴快捷键CtrlV。Typora会调用PicGo把剪贴板里的图片上传到COS然后自动在文档里插入这种网络链接整个过程大约一两秒。从这之后基本就告别本地图片路径了。4.3 验证效果把md发给别人试试配置完成之后一定要做一次发送测试这是最直观的检验方式。打开一个新建md文档粘贴三张图保存成单个文件通过微信或者邮件发给另一个朋友让对方用任意markdown阅读器打开。正常情况对方只要设备能联网图片就应该全部加载出来。我自己第一次测试时内心其实蛮忐忑的直到对方回复图片全都能看见才完全放心。这个测试还能验证一个隐藏问题如果对方用的阅读器是某些旧版本的编辑器比如旧版Windows记事本的markdown扩展网络图片也可能加载异常。这就属于工具兼容性问题了正常的主流渲染环境Typora、Obsidian、VS Code Markdown Preview、GitHub Web端对网络URL的渲染都是没有问题的。5. 实战中反复踩过的坑以及可以偷懒的替代方案图床配置好之后日常使用中还是会碰到各种小问题。我把这几年实操里印象最深的几个坑和处理方式整理出来外加一些不想折腾时的替代方案供大家参考。5.1 五个高频问题排查清单图片传上去是裂的URL无法访问检查存储桶权限是否真的设成了公有读。这是一个最常见的坑很多人配置完权限忘了保存或者浏览器缓存了旧的权限状态导致新链接仍然提示Access Denied。检查防盗链是否有误伤把空Referer允许访问打开。检查自定义域名是否真的解析成功。用nslookup或在线DNS查询工具看一下CNAME记录有没有生效。中文文件名导致URL乱码上传图片时PicGo默认会对文件名进行URL编码比如架构图.png变成%E6%9E%B6...虽然能访问但链接太丑且容易在复制粘贴时截断。我的做法是上传前把文件名改成字母数字组合比如arch-01.png既清晰又避免编码问题。PicGo有重命名文件名的设置可以配置成时间戳格式也省心。删除了旧图片N个文档全裂对象存储里的对象删了URL就404了。最危险的是清理存储桶时手滑把整个桶删了意味着所有引用这个桶的文档图片全部失效。我的经验是在下线或清理图片前先全局搜索一下哪些文档引用了这些图片。可以用VS Code对整个文档目录做文本搜索搜出img.example.com出现的位置再决定哪些对象能删。虽然图床存储价格不贵但删除图片前保持这个习惯能省去很多历史文章裂图的痛苦。图片体积没控制拖慢阅读体验图床解决了图片显示问题但大图片载入依旧慢。手机截图动不动一张35MB直接传上去别人打开文章滚动时每张图都要下载四五兆体验很差。我的做法是在本地先对截图做一次压缩。工具上我用的是一个很小的命令行工具sipsmacOS自带或者ImageOptimWindows用户可以用PageFocus或者自己写一个Python Pillow脚本。压缩到宽度不超过1600px、画质85左右既能看清细节体积能缩小到原来的三分之一甚至五分之一。私密笔记里的图片也被公开了图床公开可访问意味着任何人拿到链接都能看到图。如果你写的是私人笔记、内部系统截图、包含敏感信息的文档千万不要用公共图床。要么用私有读写权限但这样别人也看不了要么就干脆不传图床直接用本地路径自己看。我的习惯是内部敏感文档和对外发布的文档分开两个存储桶一个私有一个公有绝不混用。5.2 批量迁移和工具链补齐如果有很多历史md文件里面全是本地路径图片手动逐个替换URL会崩溃。我的处理方式是写一个脚本扫描所有md文件提取里的图片路径调用PicGo或者coscli把图片上传再把md里的路径替换成返回的网络URL。Python里re.sub加一个回调函数就能实现配合PicGo的命令行调用或者直接调COS的SDK做批量上传。一次处理几十上百个文件跑完基本就全自动了。这个脚本我每换一次写作环境就重写一次虽然不难但确实是批量迁移的刚需。另外值得一提的工具是gitbook或者mdBook这类文档构建工具它们可以把md文档构建成站点并统一处理图片资源。如果你把md托管到Git平台团队里每个人按规范提交图片跟着文档仓库走大家在Web端渲染时也不会裂图。但这条路本质上是团队级解决方案对个人博客、随手发链接这些场景图床方案依然是更通用的选择。5.3 不想折腾图床时的替代方案如果你偶尔才发md文件或者不想注册云服务其实还有一些更轻的方案可以救急压缩包直传整个目录打成一个zip发过去目录结构别动对方解压后用Typora直接打开大概率能正常显示。这是最省事、也最原始的方案适合低频、一次性的分享场景。在线工具转换把md内容复制到在线markdown编辑器如StackEdit、Dillinger里把图片上传到工具的服务器再把导出的内容发给对方。优点是零成本缺点是图片管理不透明工具的寿命有多长不确定。企业网盘开放访问如果你把文档放到一个所有人都能看到的内网盘或企业云盘里本地图片路径对别人来说依旧不可见除非你把文档转成Word或PDF再发。注意md转Word时图片是内嵌的转PDF同理这其实是非图床场景下最稳的传播方式。直接把md渲染成HTML再发Typora支持导出HTML导出的HTML会把图片以Base64形式内嵌单个文件体积变大但完全自包含发送给谁都能打开图片肯定不会裂。这个方法用来做一次性分享非常好使缺点是不适合后续大量更新文档。我个人的看法是这些替代方案都是救急不救穷只解决当下的传播问题解决不了长期、大量、跨平台的文档图片管理问题。只要你有长期写md文档的需求配置一个对象存储图床永远是值得做的基础设施投资。毕竟花费可以忽略不计省下来的却是每次发文档时图片又裂了的尴尬和补救时间。
