fleet 的界面是真的丑，浪费大片空间

爱因斯坦这个是因为被投毒了 中国灰产非常喜欢这样搞，例如谷歌翻译的 GitLab 这个词条就被菠*菜网站投毒了好几轮

@jeesk #5 不是，我记得 TLS 就是我说的这种方式设计的，太久没研究这块忘记了

我记得可以生成一个长密钥，然后非对称加密这个长密钥，实际文件内容用长密钥对称加密，这样体积就不会变大很多了

@zaunist #80 为什么不可以，我是想用状态码代替原来的 success: bool ，如果不想区分太细 200 和 400 就够用，只是 40x 还可以再细分而已

@edis0n0 #18 查询写的有问题：它只查询有绑定邮箱的用户，没绑定邮箱就找不到用户，没扣手续费，坑死了谁想得到能写成这样

@vacker #17 卧槽真的是这个原因，这个函数还 include 了一个后扣手续费的 PHP 文件 sendEmailNotice.php ，直接改余额和已产生的充值记录，单看文件名完全想不到还做了这事，那里面查询写的有问题经常找不到充值记录所以没扣手续费，不知道多少年了一直有这个问题，都是财务手工加回去的

@shakoon #63 照你这么说 stripe twitter 的程序员全都不是科班出身的吗

@eason1874 #9 查看了 MySQL 日志，确定提交的是 0.994 ，invoice 表里存的是正确的签名后的整数字符串 1 ，弄了一个单独的 PHP 文件 var_dump $paidCredit ，刷新了几次都能正确输出 1

@ysc3839 #7 反正不是我写的，没提我肯定不敢改

@fzlqr091314 #5 问题是我不确定这个小一点的问题是在哪一步产生的

@momocha #3 这套屎山代码修修补补已经运行 13 年，谁敢搞这么大改动

@hobbyliu #1 之前考虑过是这里的问题，但$currentCredit 应该影响不到变量$paidCredit 呀，topUpRecords 里的 Credits 也变成 0.994 了

@flyqie 那为什么 stripe twitter 这些国外平台都是用 HTTP 状态码区分错误呢

@xy90321 #45 照你这么说 200 状态也不一定是 API 给出来的啊，配置错了反代的时候 200 状态的 API 也有可能被缓存

@dorothyREN #10 程序重启所有签名失效 那你们上个新版本所有用户都要重新登录？

@shakukansp #31 发现很多层没理解我的意思，我的想法是少额外包装一层，直接用状态码是否 200 判断是否失败，成功的话整个返回都作为 data 处理，失败的话整个返回结果都作为 error detail 处理，这样更方便资源消耗更少
劫持问题现在基本都有 HTTPS 了吧

@shakukansp 403 400 403