IE6 糟糕在什么地方？
不是它战胜 Netscape 成为领先浏览器的时候。
也不是它市占率第一独领风骚的时候。
而是它自创标准并且严重落后于时代并且浑身 bug 的时候。

说实话，先进+独占对于开发者来说非常友好。不用考虑碎片化，不用考虑兼容性，有什么不满足？
所有的槽点都在 IE 落后于所有人成为一坨又臭又旧的大便的时候开始。

现在的 chrome，满足以上哪几个条件？
1，自创标准。其实主要是因为很多技术由 chrome 引领。一旦成为业界标准，chrome 的完成度是向来在一线的。这一点值得吐槽的应该是 Safari，新一代墨迹王。
2，严重落后于时代。并没有。
3，浑身 bug。整体来说表现还不错了。在这一点上 Safari 依然占据头把交椅。

真要说当代 IE6，倒是可以提名 Safari 和微信 X5 魔改内核。

@ericgui 听说过薅实习生毛的，第一次见薅候选人毛的。。。

倒让我想起类似的一件事。
——小张啊，前两天那个疑难问题，还没解决吗？
——领导，这个太底层太高深，我们实在搞不定。
——那这样，你写个高级工程师招聘 JD 发出去。你去面试。
——哇！您终于肯帮我们团队招募一个高级工程师 /架构师了吗？可是，我水平有限实在不敢面大牛啊。
——招个屁，面试的时候你就拿这个问题问问他。

4kw 个 int，160M，可以直接放内存。
设计一个分布尽可能均匀的散列函数（这一步不太确定我不是搞数学的。瞎拍一个 md5(obj)//4kw 的算法不知道效果怎么样？）
遍历每个 obj 求 hash，把 obj 的 index 放在对应的桶里。
如果桶里已有元素（ hash 冲突），单独放在另一个冲突列表里。
对于冲突列表里的每个冲突 hash，遍历并精确对比每个 obj，从源数据集删除完全相同的 obj。

稍微注意一下 getObj(index)的 O(1)复杂度，理论上可以应对任意量的数据了。

强蹭热点有意思吗？还有没有更具攻击性更具侮辱性的比喻？照照镜子先自我分类一下？

程序员简直是最科学最真理最硬核的职业了。我觉得比数学比物理还硬核。

撒一把枯草树枝把深不见底的真相盖住并树一个玄学的小牌牌是不对的。

技术方案凭什么要对前端透明？是因为前端不归后端管而且老大又惹不起吗？
而且有个疑问：有 2 个请求势必有 2 个响应回来，搞不好后发先至都是有可能的。如果真的前端透明，如何区分、处理这两个响应？

要拦截，也应该是请求方做拦截比较合适啊。比如说封装到前端底层库里面。业务层只管 util.post()，由底层去做判断去重和状态管理，哪怕直接黑吃了第二个请求也行。

而且原则上来说，一件错误应当尽可能的消灭在更早的阶段，而不是往后延伸到系统深处统一处理。比如简单却有效的 doubleclick.js ，直接在事件层就把双击误操作消灭掉了。带来的好处是可以尽量避免制造不必要的约束和暗逻辑并且带到系统的各个角落。

@jmc891205 那么一定会催生题库解题法。
select input {
case 123:
return 1;
case 456:
return 2;
}

不管什么类问题，时间复杂度全是 O(1)。

没有绝对的万无一失的安全。所有的安全都是 概率 vs 成本。
但就跟多因子校验一样，多一项异质、异构的因子，安全性能将大大提升。
假如数据库被脱裤的风险是万分之一，代码泄露的风险是万分之一，那两项同时失密的风险是多少？

还列教学大纲？
你这样迟早要把女票给教没了我告诉你！

正确的做法是：
1，努力学习前端，女票日常开发有哪些可以自动化的工作，赶紧写工具，优化她的日常工作体验。
2，女票日常遇到的疑难问题随时交给你搞定。24 小时待命，任务执行时间不超过 12 小时。
3，如果女票愿意，出钱送女票去培训班、夜大、脱产成教。
4，努力赚钱养家。这是最重要的。

Is life always this hard, or is it just when you're a kid?

Always like this.

@FrankHB 说分析就分析。
不要思考，不要先验，不要预定义优先级。如果我们引入了?:运算符来简化 if/else，来试试凭直觉猜测以下 y=f(x)函数的意图。

y = x >= 0 ? 0 : 1
猜它是想干嘛？
A，三目运算符具有高优先级。y = x >= (0 ? 0 : 1) => y = x >= 1 => 根据 x 是否大于等于 1 得到 bool 值。这个例子中 (0 ? 0 : 1) 表达式其实非常不稳定，条件为 0 则永假，条件为非 0 则永真，在 int 不能自动转型 bool 的强类型语言中则直接挂。
B，三目运算符具有低优先级。y = (x >= 0) ? 0 : 1 => 根据 x 是否大于等于 0 得到 y 为 x 的符号位 0 或 1。
显然方案 B 容易理解比较合理并且稳定可预期。结论 1：三目运算符优先级低于比较运算符。

再来一个。
y = condition ? x : x +1
猜它是想干嘛？
A，三目运算符具有高优先级。y = (condition ? x : x) +1 => y = x + 1，condition 在这里毫无意义。
B，三目运算符具有低优先级。y = condition ? x : (x+1) ，条件成立则 y=x，否则 y=x+1。
显然方案 B 容易理解比较直观。结论 2：三目运算符优先级低于+加法双目运算符。

这样的例子还可以举下去。
我不知道大师们在设计语言的时候是否有类似的心路历程，但以我粗浅直观的感受来说，我对三目运算符优先级如此之低表示非常舒适非常满意。

这年头，凡是有利可图 /有害可避的，他们都会重新定义一遍。

@2oTp
之前有一个小任务，直接面向 google 编程，一下午撸出来了。
现在回头想想，忘得一干二净。
等下次需要的时候再学(sou)吧。。。

basic
logo
bat
foxbase
pascal
asm
asp+vbs
vb
再往后的现在都还会用到。

@loveour 管理者的无能。
因为识别工作量、工作质量、留坑量、优雅度、工匠指数。。。这些玩意太具技术含量，太难量化，太麻烦。
相比来说计时就简单容易多了。打卡机导出即可。

换一个计件岗，管理者从来不在乎你加不加班。因为直接计件容易啊！

另一个话题，虽然对于运算符优先级我就从来没记清过，但印象里凡是自带?:三目运算符的语言，好像都是超低优先级，都是排在+-*/之后。
所知语言有限，实在想不起例外。我尽力了。

说实话，这个“坑”字的定义有问题。
坑，常用来描述反常理的，有 bug 的，太 trick 绝大多数人都不知道的旮旯。之所以是坑，就是绝大多数人都会掉进去。
而运算符优先级，既是常理，又没 bug，也一点 trick 都没有。这不是坑，这是基础知识存在盲点，是个人问题。