我们知道这样可以加载头像：
因此，我提出了优化的方案：
到这里有一些人可能就会问了？为什么不直接用QR自带的缓存呢？
这里我要说一下QR自带的那个缓存的缺陷，对于随机图的API，勾选了缓存则随机图的输出不会刷新（始终是那张图片），因此采用这种方案
然后我这种方案可能也有人考虑到了，这不是增大了手机内部存储的容量消耗吗？的确，所以要根据实际的应用场景来决定方案。
后续补充：
但是这个也有一个弊端，就是头像发生更新后不会自动更新，解决办法可以配合定时（按月、周……）使用md5校验图片，或者干脆直接定时（时间戳差）更新图片
另外已知QRSpeed的调用或回调函数使用过多会异常卡顿，这有一个重要的原因，很可能是算法的逻辑问题，所以可以合并回调到需要的内容中去，或者直接不要输出头像（纯文字）
原作者xiwangly，这个主题是我自己想的，如有雷同，纯属巧合。
但是这种写法每次都要访问这个网站，不仅增加了这个网站的流量压力，而且也影响了回复速度，（并且对于使用数据网络挂QR的用户来讲，进一步扩大了数据流量的消耗）
因此，我提出了优化的方案：
变式：（偷懒的写法）
这个方案的主要目的就是将头像缓存到本地，然后读取本地的图片，加快回复的速度等……
到这里有一些人可能就会问了？为什么不直接用QR自带的缓存呢？
这里我要说一下QR自带的那个缓存的缺陷，对于随机图的API，勾选了缓存则随机图的输出不会刷新（始终是那张图片），因此采用这种方案
然后我这种方案可能也有人考虑到了，这不是增大了手机内部存储的容量消耗吗？的确，所以要根据实际的应用场景来决定方案。
后续补充：
但是这个也有一个弊端，就是头像发生更新后不会自动更新，解决办法可以配合定时（按月、周……）使用md5校验图片，或者干脆直接定时（时间戳差）更新图片
另外已知QRSpeed的调用或回调函数使用过多会异常卡顿，这有一个重要的原因，很可能是算法的逻辑问题，所以可以合并回调到需要的内容中去，或者直接不要输出头像（纯文字）
原作者xiwangly，这个主题是我自己想的，如有雷同，纯属巧合。
最后编辑:
