目录
场景
最近笔者做的项目中,有一个需求:
在系统中生成一个二维码,用户保存下来并分享出去,其他人扫描之后跳到我们的一个活动详情页,查看此活动的内容。
从以上的需求中,可以提炼出以下几点:
- 当用户点击生成二维码的时候,我们要拿到用户生成的二维码是关于哪个活动的;
- 请求来到后台,拿到活动ID,作为我们活动详情页的参数,生成一个url,作为扫描之后的跳转地址,生成二维码;
- 把生成的二维码,返回给前端,展示给用户;
- 用户保存二维码,即下载下来。
以上就是全部业务流程,其中第一步、第二步无关紧要,只是给二维码设置内容而已。这里需要提一句,二维码的内容,可以是一段明文,也可以是一个http或https链接,当扫描时会自动访问这个链接。对于大部分的场景,不能说大部分,应该说99%以上的场景都是给二维码的内容设置为一个链接,扫描之后跳到对应的页面再去执行业务,除非你玩个花样,设置内容为明文“我爱你”,然后把二维码发给你的女朋友……
方案分析
我们重点分析第三步和第四步,即二维码的生成和用户下载二维码。
因为第一步、第二步就是怎样生成二维码,市面上有很多依赖包,拿来用就行,重点是如何优雅地返回给用户以及供其下载。其实让用户下载这个动作,也不是很必要,毕竟大多数年轻人都知道长按保存,但还是要照顾一下其他的用户,给出明显的下载按钮。
先说第三步,二维码如何返回给前端?也许很多人会想到,把生成的二维码存到服务器上,再把图片路径返回不就行了?这样当然可以,但是却多了很多不必要的操作:
- 对于二维码,我们只需要返回给用户即可,并不需要存到我们的服务器上,这没有任何意义,还占用磁盘空间;
- 如果将二维码写到服务器,就需要跟磁盘IO打交道,这是昂贵的代价;
- 每一个用户生成的二维码,都对应一个URL,很乱
我们可以直接将生成的二维码图片,以IO流的方式,通过response响应体直接返回给请求方。第一,不需要落到我们的磁盘,一切操作都在内存中完成,效率比较高;第二,所有生成二维码的请求,都可以访问这里,前端直接拿img标签的src就能访问,你在浏览器直接输入这个路径也能得到一张图片,减少了很多交互和逻辑处理。
再说第四步,我们直接在前端实现,因为前端有一种机制可以将某个img标签的图片下载下来,不需要浪费我们的服务器。
第一步——引入依赖
需要引入两个依赖包:
<dependency>
<groupId>com.google.zx