@julyclyde 额，确实我写草率了，应该是同一条线路可切换方向但不可同时传输。

打一通电话，既有听筒又有话筒，能边听边说，这就是全双工。
两个人拿同一个电话，一个只用听筒听，一个只用话筒说，就是你说的多线程，这并不影响这通电话是按全双工的方式工作的，只是你这端把收发分别处理了而已。

如果是半双工电话，那通话就要同时打两通电话，第一通设置为只能你说对面听，保持住，然后再打一通，设置为只能你听对面说，这样两边才能对话。

@Mac #41 这是最正常的脑回路啊。
小区很多开锁同行，如果每个人忘带钥匙的几率大体上相等，那么肯定越多人找你就挣的越多，房东可以对接自己的租客、原租客、同行的租客，这种“大流量”入口给点定向优惠不是双赢么？

问一个问题：如果拿到大几百的是你，你还反感不？

@wxw752 看着你的头像就好像你在对 LZ 说：“想让我改？吔屎啦你！”

“妈，你最近给我爸零花钱挺松啊？一天到晚吵吵买彩票，也没见中过多少钱拿回家来。。。”

#8 开始时两张表够用，中期通用的逻辑慢慢便多了，再抽出一个和身份无关的通用 User 表，对同一个实际用户的不同身份做关联，再往大做，你的前后两个系统规模都很大了，要做拆分的时候，User 表也就该拆成独立的服务了。

用户放不放在一个表里，最根本还是看怎么用，比如教育类的 app，老师和学生完全是两个身份，所有查询基本都不通用，那放一个表里就很难受，前端用户和后台用户一般也是这个情况，除非是类似 QQ 空间这种，空间编辑后台本身也是用户功能的一部分，这种就不需要拆分。

@xuanbg #14 不同意你说的，这不是认为区分两种用户，而是两种用户正常情况本身就是无关的，强行耦合在一起才会有问题。
用户的查询逻辑一般都是关联用户的业务表的，这种查询大小是会随着用户量增长快速扩张的，后台账号则是关联另一套后台业务表，数据量可能小的多，如果耦合在一起，每次查询某一套业务的时候都要用条件过滤掉另一个类型的账号，这种额外开销是没有意义的。

最好不要混在一起，外部用户表和后台用户表是两回事。
业务复杂以后可以引入独立的用户服务，外部用户库和后台用户库各自分配不同的 app_id，在用户服务中做统一的处理逻辑。

分号和引号两个流量明星还管不住你个小拇指？还想按右 Shift ？

@sleeepyy 声网一个做音视频服务也能做 app 了？
clubhouse 官网发的招聘信息也是掩人耳目的对吧？ https://jobs.lever.co/joinclubhouse?team=Engineering

@peapods 如果低水平面试高水平就叫“班门弄斧”，那普通中小厂想找个专家是不是简历看着漂亮就可以叫来聊薪资了？

又不是加回 magsafe 就得取消 c 口。。。
c 口不够可以加 hub，magsafe 没有了就是既不方便又不安全，也没有稳定靠谱的替代方案

@newtype0092 只问->质问

一个自己接口都调不通的后端，都能只问你，你还“忍得住”，你很自豪么。。。太废了吧

有什么木匠活能比造一个木屋有意思呢:)

额。。。我看成有“碰到有赛博人克隆自己该怎么办”。。。。