代码写错，差点亏了几万！

[导读]大家好，我是小林。这一周都在带大家免费领取一年阿里云服务器的活动，现在已经超1000人购买了，昨晚我就开始在部分群陆陆续续返现，几万块，刷一秒就没了，场面很壮观。还没返现的群，稍等一下，这周都会一起搞完的。这次阿里云服务器，我和小北组队了，因为我们之前6月份搞过一次阿里云白领活动...

大家好，我是小林。

这一周都在带大家免费领取一年阿里云服务器的活动，现在已经超 1000 人购买了，昨晚我就开始在部分群陆陆续续返现，几万块，刷一秒就没了，场面很壮观。

还没返现的群，稍等一下，这周都会一起搞完的。

这次阿里云服务器，我和小北组队了，因为我们之前 6 月份搞过一次阿里云白领活动，所以担心一个人搞的话，带不到大家白piao，因为当拉新用户到一定数量，阿里云才会给我们奖金，比如 1500 人的奖金是9W，这样我们才可以给 1500 人返现 60 元，也就是把奖金全部返现了。

活动最重要，也是最麻烦的环节就是返现环节，这次我们是通过一个链接收集大家支付宝账号，然后进行支付宝批量转账。

但是这个工作看起来很简单，其实有很多东西需要留意的，因为涉及到钱，最基本的要保证幂等性。

什么是幂等性呢？用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。比如这次返现活动，在收集大家支付宝信息的时候，不管用户提交了几次信息，最终只转账一次。

返现的程序是由小北实现的，他在实现的过程中，差点就因为这个事情差点亏了点钱。

以下是小北对这次返现的复盘：

不是组织了一场新用户免费领取一年阿里云服务器的活动了，现在已经超过1000人购买，750 人收到了返现，不禁发出还得是北哥的感叹！

但是在短时间内给近1000人返现，并且还要保证它们都是符合返现条件的，就不太容易，今年 6.18 我们是写了一个检测工具，自己检测后截图给我们，我们拉群，满100人发红包。

这样会浪费整整周六一天的时间，最近了解到支付宝有批量转账能力，于是我就发了个问卷向大家收集一波阿里云ID、支付宝账号用于返现。

这样直接用阿里云每天导给我的订单数据做校验，看哪些用户购买了，有资格返现。

本来非常简单，所以就让小老弟去帮我写代码，结果怎么着，小老弟的代码一小时就写完了，而且用得很爽！

于是前天晚上我就回去看了下小老弟的代码，结果一看吓一跳，差点让我亏几千上万都有可能！！

简单来说支付宝批量转账，需要生成一个 csv，每一行是：支付宝账号，姓名，转账金额，备注这样的信息。

小老弟的代码是这样写的：

users = get_user_info_from_file() //  从腾讯问卷下载的大家提交的返现信息 csv文件导入

order_map = get_order_map() // 从阿里云导出的订单数据生成一个 map，key是用户的阿里云ID，value是订单信息

for user in users:

  if user.aliyun_id in order_map:

     csv_file.writeline(xxxxxxxx)  //  有购买记录的读者信息写入csv文件，用于批量转账

然后这个产生的 csv 文件就可以传到支付宝 PC 端的批量转账接口中进行转账。

这代码完全能正常工作，也能完成返现！

但是！！！

小老弟没有考虑到异常场景，以及应对各种羊毛党或者用户的错误操作

比如说，假如一个用户在填问卷的时候填了多次信息，上面的代码是不是就会导致多次转账？

当然，这样的用户不多，但是总有大意的读者多点了一次提交之类，后来我就发现了：

当然，这样的读者比例不多，但是 1000 个用户，十几个还是有的，你就得多返现几百上千。

（PS：让我想起了后端不能相信前端，不能相信用户输入的数据

如果面对更多的读者，或者你读者里有羊毛党，他就是恶意多次提交，你是不是就得亏死？

这个返现，不是一次就搞完的，是分批的，订单数据一天导出一次，每天晚上我都会运行这个脚本进行返现。

那如果是昨天已经返现的同学，今天又来提交一次，这种又该怎么办呢？这个问题实际上是怎么做幂等、去重。

因为这个订单数据不是实时的，一天导出一次，但是读者随时可能去填表单。