在Github存放Markdown文档，如果图片没有存放在Github服务器上，github会尝试生成Github图片缓存，使用Github图片缓存，进行实际的展示。但比较蛋疼的是，如果原图片尺寸很大，缓存图片失败，会只显示一部分图片内容。
预览图显示
原图缓存图对比
缓存图片的格式大概是这样
arduino
https://camo.githubusercontent.com/ac3c95be743bed67a21823a6fc976264729c84678d5fd557aca8c71bf5a5a632/68747470733a2f2f63646e2e66616e677975616e7869616f7a68616e2e636f6d2f6173736574732f313631353532393239373634385244376843686a7a2e6a706567
解决方案
如果我们发现图片有问题，需要手动触发Github图片缓存，运行 curl -X PURGE {图片url} 即可
arduino
curl -X PURGE https://camo.githubusercontent.com/ac3c95be743bed67a21823a6fc976264729c84678d5fd557aca8c71bf5a5a632/68747470733a2f2f63646e2e66616e677975616e7869616f7a68616e2e636f6d2f6173736574732f313631353532393239373634385244376843686a7a2e6a706567运行curl -X PURGE触发重新缓存后，再次使用浏览器尝试访问图片url, 可以看到完整的图片 (如果依然不完整，就多触发几次)
如果你想完全规避以上情况，建议直接将图片存储到github仓库，我写过一个开源小工具，专门用于把README.md里面的图片进行一键转储
小结
缓存问题是编程领域的经典问题，用得好可以节约珍贵的算力，提升用户体验，做的烂就全是bug, 我觉得设计缓存机制最基础的原则就是可以很方便地清理缓存，就像Github的图片缓存一样，即使缓存有问题，也允许用户通过简单的命令清理旧图缓存，触发新缓存。