啊呀这样说还是有歧义，尝试解释一下：

QQ 邮箱体系内，可以当做域名邮箱使用的，有两个业务：
域名邮箱 和 企业邮箱

截图里的，是那个叫做 “域名邮箱” 的域名邮箱服务，估计以后慢慢就关掉了。
与此同时，那个被叫做 “企业邮箱” 的域名邮箱服务，还是可以正常使用的。

以及，那个被叫做 “企业邮箱” 的域名邮箱服务，并不是只有企业才可以用。

再以及，如果你只是自己用的话，不需要担心帐号数量限制，配置好全域邮件转发就行了。


以上这一大串，充分说明了，好好给产品起个名字有多重要。

楼上诸位，区分清楚 “域名邮箱” 和 “企业邮箱” 啊，这是两个不同的业务…… 企业邮箱那边是正常用的

咦，原来这个飞猪就是 NOMO 的 flypig 啊

我觉得你对 “重放” 是不是有一定的误解？

“防重放” 一般防的是第三方监听了一个 “有效请求” 之后，通过再次发送这个请求来达到一些其它的目的。

举例：
张三 使用某银行 APP，向 李四 转账了 100 元，银行 APP 调用某接口，正常的完成了这个请求。

但是这个请求被 王麻子 通过中间人攻击监听到了；
> 此处为防监听，也就是 https 常见的工作内容）
> 王麻子由于未持有银行域名的 https 证书，未能完成监听

于是王麻子把请求原样发送了 3 遍，期望张三给李四再转 300 元；
> 此处为防重放，一个活儿不能干多次
> 由于银行记录了请求 ID，直接忽略了这 3 次请求

王麻子又试着把请求中的收款人改成自己，期望能收到张三的转账；
> 此处为防篡改，保证执行的内容和发送者发送的一致
> 银行校验请求签名不一致，直接拒绝了这个请求，同时把请求留档给了安全部门



而抢票软件干的事情相当于什么？
张三 使用某银行 APP，向 李四 转账了 100 元，转账 ID 01。
张三 使用某银行 APP，又向 李四 转账了 100 元，转账 ID 02。
张三 使用某银行 APP，又向 李四 转账了 100 元，转账 ID 03。

这三个请求是互相独立的，不叫 “重放” ，只是恰好业务一致而已。

既然你已经意识到了精度问题，那么完全可以定义一个精度阈值：

类似：const double eps =1e-7;

然后最后一个 else 改为：else if ( fabs ((mid * mid) -num ) < eps )

如果害怕面试官看不懂，在 eps 那一句再加上个注释就好了。

@LinJunzhu #52
无奈脸，所谓的设置 JSON 对象设置的是什么？

就是一个正常的 http post，以 JSON String 作为字符串 body，
再覆盖 header 里的 Content-Type 为 "application/json" 嘛……
自己手动处理下 header 不就好了么…………

requests / okhttp 它们自己也是这样干的啊……

https://github.com/psf/requests/blob/master/requests/models.py#L463

https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/guide/PostExample.java#L15

如果不想这么处理，一定要传 JSON Object 给框架，那么相同的思路我在 6 楼和 10 楼提到的 JSON String 的方式，实质上是一致的。

如果是 Linux 的话，建议复习一下 Linux 的权限机制。


这里涉及到你这个 go 程序是用什么用户跑起来的。

假设是用 www 用户跑起来的，那么你现在相当于在利用这个 www 用户进行读写。
而你上传上去的程序，正常情况下也只能以 www 用户的身份被调用。

你可以改变思路来想这件事儿：
你现在相当于登录了这台主机的 www 用户，你能做哪些操作？

如果这个 go 程序是用 root 用户跑起来的，那么你可以粗略的理解为你现在有了 root 用户的权限，那就可以为所欲为了。

这也就是为什么 nginx / php-fpm 之类的一般跑在 nobody / www 用户下的原因，只要我对这个用户的权限把控的足够好，你即使拿到了这个用户，也翻不起什么波浪。

另外，request body 的方式，和我在 6 楼 10 楼 提到的 “JSON String” 的方式，其实思路上是一致的。

都是通过传递已经被 序列化 后的 JSON String 来保证签名和验签一致的。

换一个方式说：
JSON 的无序，体现在 JSON Object 被 序列化 为 JSON String 的时候，无法保证不同的序列化方式序列化出的 JSON String 是一致的。

而 request body，本身就是一段已经被 序列化 好了的 JSON String，这段已经被 序列化 后的字符串，是可以确定不变的。

如果你经常使用一些 web 请求框架的话，由于框架的封装，你也许会以为自己发送和接收的是 JSON 对象。
但是要搞清楚的是，你收发的只是一串符合 JSON 规范的字符串而已，对 HTTP 来说这和 “hello world” 没有区别。

除非你的请求中间有被篡改过，否则，客户端发送的 request body，和服务端收到的 request body，应当是完全一致的字符串，HTTP 是不会把你的 “hello world” 变成 “world hello” 的。

为什么说你对 HTTP 的了解确实不够深，因为你把下面两件事搞混淆了：
[可能不一致] A：JSON Object 被 序列化 为 JSON String
[确定一致] B：JSON String 被填充在 request body 发送给服务端

@LinJunzhu
request body 就是一串纯文本，可以理解为一个 String，在被解析之前，它是固定不变的，完全不涉及到底是 json 还是 xml 还是 form 的问题。

你的思维被 json 禁锢住了，request body 是更高一个层面的东西。
以及，这样算出来的 hash，需要加在 header 里面，不能动 request body

@LinJunzhu #19
直接对 request body 进行验签是可取的且并不会被乱序干扰到，只能说你确实对 http 协议不够熟悉……

个人非常不建议把路由替换成软路由。

大部分人的软路由需求，其实搞一个旁路由完全可以解决。

2200G 的自带散热器，我用小刀削了一圈儿就正常塞进去了。
没注意 3400G 是否是同一型号的。

@wasd6267016
你应该结合 @GPLer 回复的那个知乎链接，里面的第 2 个回答来看。
我猜测你把这些文本直接放在 CF_TEXT 了。

@ladypxy
我好像没有说 iOS 会提示？
我说的是 Android 会提示啊……