说了，你就是看到问题就怂。自信更重要。

@phpfpm 这就很迷惑了，哪来的？
这样 aliyun oss 嫌疑就很高了。

@jxf2008 钱不是万能的，但没有钱是万万不能的。

盲猜一个后面都是 0

不明白，请给出情景详细说明

location.href 被设置进 dying，dying 状态下是否执行是未定义的。
就算 throw 也不一定，如果有 setTimeout setInterval 的代码也还是会执行。
即使跳转发生或者完成，有时也会有未完成的请求继续发送。

另外，所谓被骗的贪便宜，完全就是贪小便宜。
“强卖算送+三倍赔付，你先得给我免了这六千，再给我转一万八，给你 20 分钟到账不然投诉你”

@Free3 #161 我认为关于隐私，“虚假的安全” 更加危险。你认为自己凡是 A 处叫张 A，B 处叫张 B，但并不能保证某个偏门的地方恰好得到你的真名。这时候违法分子报上你的真名比平时一直暴露真名更加危险。
我选择把真名放得到处都是，“是个人都知道我的名字，那么你报上我的名字没什么特别的”。

@delectate #145 注意：
对于冷读热读，越是 “觉得” “自己不会被骗” 的人越容易被骗，更不用说 “竟然还有人会被骗” 的思路了（换句话说，你是被骗高危人群）。唯一的应对办法是时刻的审慎和怀疑，把怀疑当习惯，但这样人的精神状态不会太正常的，会显得有点 “神经兮兮”。
另一种思路是对自己植入特定行动时的触发器：我们都相信葛朗台不会被骗，如果你将对 “付款” 这一行动植入 “怀疑” 这一情绪，那么轻信会在这时惊醒。

但依然挡不了更高级的社工技巧。甚至有被骗了，骗完了还不相信自己被骗的，骗子已经供认，受害人还要为其请愿的，骗子已经判刑后还要去看望的。只能一点点纠正回来。

劝分是你的事，我的建议是不要替其承担，最多帮助承担。失败并不可怕，重要的是从失败中学到什么。

@delectate 有理有据，令人信服。(bgm38)

@no1xsyzy 好像建立了索引还是，刚没细读，搜不出来的情况 ORDER BY DESC + LIMIT 1 时间很长，用了 JOIN 就 1200ms 以上，写成子查询才保持始终最短时间。
综上，A/B 测试吧。

就当我口胡吧，似乎两者功能不完全等价。
https://stackoverflow.com/questions/34246403/performance-of-max-vs-order-by-desc-limit-1
ORDER BY DESC 会导致 NULL 在最前，所以有 NULL 的时候 2. 选出来的那个一定是 NULL。

而该提问应该是没有索引导致的问题，而根据是否能选出至少一行（有 WHERE 所以不一定能找出来）：
找得出来的情况 ORDER BY DESC + LIMIT 1 效率比 MAX 高；
找不出来的情况 MAX 效率极高。

如果有索引我认为两者基本一致，因为不会需要进行一次排序。

SQL 的优化是数据库帮你完成的，不同的实现可能不同，不过我认为至少存在一个数据库软件这两者是等价的，甚至你写 2 都直接给你优化成 1 实现。
那么，谁来试一下 PostgreSQL 的优化是否包含 ORDER DESC LIMIT 1 == Max ？
不过如果没有该优化应该选 1 ；同时为了语义也应该选 1。我看不到选 2 的情况。

目前的人工智能存在方向性错误。
在系统一上做得比人类更好了，但系统二是基本一点没有。
让人类超越其他动物达到现在这个程度的，我认为是系统二，其中包含了抽象的能力。是抽象的能力使得人与人之间可以相互学习。

@openbsd 人类正在以某种方式尝试奴役蟑螂，用于处理厨余垃圾并做成蛋白质补充剂（给鸡吃）。
新华网 http://www.xinhuanet.com/local/2018-07/20/c_1123151869.htm
新浪新闻 https://news.sina.com.cn/c/2018-12-16/doc-ihqhqcir5432249.shtml

所以说域名邮箱才是正确的方式，拿个 *.tk 的做个域名邮箱就行了。

istream& operator>>(istream& is,char*& x)
这个定义无法匹配到 cin >> "bbbb" 这一部分。
因为 "bbbb" 不是 char*& 类型的而是 const char* 类型的。
首先它是个 const，其次它不可变所以不能有 &。
——
请明述需求。