背景
Markdown（简称MD）是一种轻量级标记语言，凭借其简洁的语法和对纯文本的专注，在技术文档撰写、笔记记录等场景下得到了广泛应用。它允许我们将格式与内容分离，最终可以轻松转换为HTML、PDF等多种格式，极大提升了内容创作的效率。
然而，便利性的背后也存在一个常见问题。当我们在本地使用Markdown编辑器（如Typora）写作时，插入的图片通常是引用的本地路径。这意味着，如果我们将这个.md源文件单独发送给他人，或者发布到不支持本地上传的平台，对方打开时所有的图片都将无法显示。传统的解决方法，如将文档导出为不可编辑的PDF，或者将.md文件和图片文件夹一起打包发送，都显得不够优雅和高效。
要从根本上解决这个问题，就需要引入“图床”的概念。简单来说，图床就是一个专门用来存储图片的网络服务器。我们将图片上传到图床，它会返回一个公开的URL链接。在Markdown文档中，我们用这个URL替换本地图片路径，这样无论文档在哪里被打开，只要有网络连接，图片就能被正确加载。
其实最初是想折腾一下自建图床的，也研究了一些开源方案，比如功能强大的S3兼容对象存储 MinIO，或是专门的图床程序如 hevereto 等，可以通过 Docker 方便地部署在自己的服务器上，数据的完全私有化也很有吸引力。不过，考虑到很多文档和图片资源需要在一些重要场合使用（比如面向业主的汇报材料或是大型培训的讲义），长期使用的稳定性、图片的访问速度就成了必须优先考虑的因素。自建服务固然有掌控数据的乐趣，但也意味着要自己承担网络波动、硬件故障等潜在风险。恰好当时阿里云在做活动，“OSS标准存储包”40GB一年的费用仅为9元，综合考量下来，这个成本远低于自己维护一台服务器的精力开销。最终，还是选择了阿里云OSS作为更稳妥的方案。
注意！
使用OSS时要注意防止流量盗刷。之前关注的某博主就因OSS存储桶（Bucket）的公网访问权限配置不当，被恶意程序在短时间内刷掉了巨额流量，据说是一周被刷掉了几万块。因此，在开通OSS后，务必第一时间在费用中心设置一个消费预算告警，例如每月消费超过10元就发送短信或邮件提醒，并设置封顶阈值，尽量规避风险。
配置
有了存储图片的仓库，下一步就是如何让写作流程自动化，实现“图片即插即用、自动上传”的无缝体验。这里采用的组合是 Typora + PicGo。
PicGo是一个开源的图床上传工具，它像一个中转站，可以接收来自剪贴板或本地文件的图片，然后根据配置好的插件，将其自动上传到指定的图床（如阿里云OSS、腾讯云COS等），并返回相应格式的链接。
配置过程很直接：
安装PicGo：从其官网或GitHub仓库下载并安装客户端。
配置PicGo的阿里云OSS插件：
在PicGo的“插件设置”中搜索并安装aliyun-oss插件。
在“图床设置”中找到“阿里云OSS”，并填写配置信息。这些信息都可以在阿里云的控制台找到：
keyId 和 keySecret：访问控制（RAM）中创建的AccessKey，建议授予仅有OSS写入权限的子账户，以实现权限最小化。
存储空间名 (Bucket)：你创建的OSS存储桶名称。
存储区域 (Area)：例如oss-cn-hangzhou。
指定存储路径：可以自定义一个文件夹路径，如img/，便于管理。
集成Typora与PicGo：
打开Typora的“偏好设置”，找到“图像”选项。
在“上传服务设定”中，选择“PicGo(app)”。
指定PicGo应用程序的路径。
点击“验证图片上传选项”按钮，如果看到成功提示，则说明整个链路已经打通。
完成以上配置后，整个工作流就变得非常顺畅。当在Typora中粘贴或拖入一张本地图片时，PicGo会自动在后台接管，将其上传到阿里云OSS，然后将返回的URL链接替换掉文档中原始的本地路径。整个过程几乎是瞬时的，对于写作者来说完全无感。
至此，Markdown文档的图片引用问题得到了一个比较完善的解决。它确保了文档的独立性和可移植性，无论是在不同设备间同步，还是分享给他人，都能保证图文并茂的完整呈现。虽然前期需要一些简单的配置，但这种“一次配置，长久省心”的投入，对于维护一个清晰、可靠的个人知识库而言，是值得的。
评论区