感谢反馈。第三方图床替换 这个配置不打算加，因为 Solo 本身是作为 B3log 分布式社区博客端节点来设计的，并不是一款通用的博客系统，所以不加入第三方图床，仅支持使用社区图床。

大致的实现逻辑是通过配置 Vditor 的 linkToImgUrl 参数来启用图片抓取上传功能，后端参考 Vditor 文档来实现该接口：HTTP Client 拉取图片，然后上传社区 https://hacpai.com/upload/client（可参考现有浏览器端请求实现，所需参数 uploadToken 可以在 Solos.java 中找到）。

这个功能稍后我来做吧。

最新镜像已经包含这个特性了，楼主有空的话帮忙测试看看，谢谢。

概述

该功能使用时，只能在复制单独外链图片链接的时候请求才会被触发（例如：直接在编辑框中输入
如果复制大段包含外链图片的文字，则该功能不能被触发。
具体情况如下：

1. 直接在编辑框中输入外链图片链接可以被触发，并且正常使用：

2. 复制大段包含外链图片的文字，功能不可能用。并且文本框没有触发请求。

   

3. 在文本框中输入的外链图片如果之前上传过一次，再次粘贴是不会被触发，并且外链不会被替换掉

   

原因分析

情况1和情况3的出现，可能和编辑器渲染的时候缓存逻辑有关，可能第一次上传之后会缓存图片，如果第二次使用该图片，不会去服务器请求而直接使用缓存好的。

情况2的出现，我不太能分析出原因。因为我在浏览器控制台，调试时，我发找到editor.js文件内容，只找到了admin.min.js。所以不太清楚editor.js起作用的时机，没法调试。

概述

首先，您的代码确实写的很漂亮，但是关于这段图床上传的代码，我有一个不太成熟的建议。考虑到浏览器段可能会重复提交请求来上传图床图片，因此会出现一个图片地址被重复提交多次（在编辑框编辑时，这种情况也会发生）,如重复提交多次http://img.vcjmhg.top/20200323103828.png。如果每次提交都上传图床一次，会增加图床的压力。

解决方案

因此可以考虑增加一个缓存，每次请求后，在处理完成封装JsonObject之后，将originalURL和communityImageUrl用CurrentHashMap缓存起来；下次如果有同样的originalURL请求过来的时候，直接存缓存中取。取得时机可以在FetchUploadProcessor的68行之后，即判断完请求的originalUrl不是以社区图床开头(https://img.hacpai.com)，之后来判断请求的originalURL是否在缓存中。

关于删除缓存的时机，可以考虑在提交文章之前，清空本次编辑过程中产生的图片URL缓存。

当然另一种思路则是创建缓存时设定一个固定的大小（比如20，因为对一篇文章来说20张图片大部分时间是足够的），如果缓存数量超过20，则删除最早进缓存的url。

由于solo的源码这几天刚看，可能某些地方理解不到位。不太清楚这种解决方案是否可行。也或者您考虑到了这种情况，我只是理解有问题。

直接复制 markdown 原文不会处理，只有在复制 HTML 或仅有图片的的时候会进行处理。如果复制 markdown 原文也需要处理的话需 @88250 为 Md2VditorIRDOM、 Md2VditorDOM Md2VditorSVDOM 添加 renderLinkDest 回调

重复上传的问题社区接口应该是有处理过的。

@vcjmhg 感谢反馈！

1. 没有自动拉取上传的场景可能是因为粘贴的内容是 Markdown 纯文本，正如 @Vanessa219 所说，稍后我们会在编辑器内加入这些回调场景的处理
2. 客户端缓存是个好建议，可以减少重复请求提升性能。但一般情况下一篇文章不会存在重复图片的情况，所以就没有加缓存优化了；社区图床实现上已经通过内容 md5 去重，如果是一模一样的图片就直接返回地址了，不会重复保存

别的就没有问题了，谢谢！

Vditor 编辑器项目的分屏预览（SV）模式已经重写完毕，这周 Solo 会进行升级。

Vditor 编辑器升级至 v3.3.8，已支持此项特性，稍后发布 Solo v4.3.0。