在一个需求中涉及到海报分享，需要让用户长按海报分享给朋友。
问题概述
在测试环境，分享海报的时候，分享出去的海报是半截的，未渲染完成的。
问题描述
前端使用两张图片，一张在下层，是给用户展示的图片；另一张采用透明的效果覆盖在上层，是用户实际保存和分享的图片。
后端以流的方式返回图片给前端，前端用两个img标签的src属性去接收这两个流。然后用两个图片的onLoad事件去监听图片已经加载完成。
问题的现状是，当用户在分享的时候分享出去的是未渲染完成的海报。
追查原因，发现当长按上层图片时，微信会端触发一个机制，在非常短的时间内去获取这个图片，而这个图片的数据是流的形式返回的，如果网速稍慢，微信拿到的就是不完整的图片流。
而我们在线上是没有这个问题的，因为线上的服务带宽高，数据流返回速度快。所以在微信获取图片的短暂时间内，就已经完全返回整张图片了。
虽然这个问题用增大服务器带宽的方法，可以加速流的返回，解决这个问题。
但是总是一种治标不治本的方法，还是需要一套备用的解决方案的。
备用解决方案
于是我在测试环境测试了以图片URL的方式进行分享，发现完全没有问题。
我猜想，以前之所以以流的方式传输，是为了避免每次都在后端生成一张海报然后保存其URL。
但是这确实是一种治本的方法。目前作为备用方案吧，毕竟在后端大量保存一些无用图片太浪费资源和空间了。
当然这种缺陷也是可以解决的，那就是每次在返回这个url之后，跑一个定时任务，在10s（只要定时时间大于拿到图片所需的时间）以后去清除这张图片就可以减少空间的消耗了。但是却也给服务器性能带来了压力。
海报分享只获取一半/获取不到，报错ERR_CONTENT_LENGTH_MISMATCH 200 / ERR_INCOMPLETE_CHUNKED_ENCODING
的原因：
首先，知识点—> 当代理文件大小超过配置的proxy_temp_file_write_size值时，nginx会将文件写入到临时目录下，默认为/proxy_temp，需要目录的写权限。
然后，我们的proxy_temp_file_write_size 为 默认的64KB，海报大小为120K左右，启动nginx的用户没有proxy_temp目录的写权限。
