@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 都没有。这不是坑，这是基础知识存在盲点，是个人问题。

1L 的办法触动了某些辛苦又委屈的客服。
但是：
1，这个办法只是对机器的，不是对人的。虽然人工介入后可能会听取用户之前沟通过程中的全程录音导致受到溅射伤害，但希望客服理解这句话的含义是 anti-AI。
2，找客服的时候都已经是逼不得已火冒三丈的时候，客服抱怨用户这个小策略可以理解，但谁来理解用户火冒三丈的时候还要忍耐制杖 AI 一遍遍答非所问的超冗长引导和过滤？最大限度的理解用户、安抚用户、满足用户难道不是客服这个岗位的本职工作吗？
3，有规则就有对策，大家都不傻。既然对方的规则就是“ 1，以闹优先，重点解决特别难搞的用户。2，特意引入制杖 AI，有效过滤客户，有效降低企业成本。”那人民群众自然会想出对策。温文尔雅的小姐姐在打客服电话的时候泼辣的像个饱经风雨的大妈狂暴的像个发情未遂的狮子，放下电话瞬间恢复淑女形象的场景在办公室屡见不鲜。没办法，温柔平和讲理的用户解决问题难度高了不止一个数量级。策略，都是策略。戏精，都是戏精。
4，综上，谁这么 2b 的给客服团队制造了这么制杖这么容易激化情绪的工作流程和技巧策略？谁为了压缩企业成本想尽办法不择手段的惹客服和用户两头不开心？冤有头债有主找那个决策人，他才是你们应该抱怨应该诅咒的人。

5，加一句废话：客服是一个非常考验耐心、遭遇负面情绪非常多的职业，非常影响个人生活和心理健康，同时国内外大多数企业对客服角色的重视程度也导致这个职业长期发展路线非常糟糕。对于个人来说真心建议早点离开这个行业。对于整体来说愿天下所有人都只有快乐没有沮丧委屈和无助。