“肇事女司机”，
“黑人抢劫犯”，
“素质低下的东北人”，
“宰客的少数民族”，
“傻✘Java 后端”……

话说这和 Java 没关系吧。

纯硬件上来讲，现在没有几家手机厂商是自己做硬件的，基本上都是组装整合。

小米的优势在于营销以及软件上能将各个厂商的硬件妥善整合到一起。

之前折叠屏的事件，很多人也都是否定小米的硬件但任何他们的软件适配能力。

我觉得问题不在“好吧”，而是在前半句。

前半句是命令式的，属于“侵略性”沟通，不管后面有没有“好吧”都会让人感觉不爽，你觉得是“好吧”的问题可能只是因为太多次听到他说“好吧”，引发了条件反射。

@markchang 模具上没啥问题，就是键盘比较闹心，容易进灰尘，然后就会出现打不出字或一下打出 2 个字的问题，不过我平时都是外接键盘用（缓解手腕问题），所以也就忍了，据说 MBP2018 加了层膜，不知道是否有改善。

用 LLVM 把 C、C++写的 GBA 模拟器转成 Web Assembly，应该能接近原生编译的性能。

不过不知道微信支持的怎么样，微信开发工具基本上都是黑盒吧，摸索起来挺痛苦的。

看头像进来的。。。

如果能找到靠谱的医生的话，看看医生是否有什么建议，因为瘦并不一定就是因为热量摄入过少，消化系统、激素系统问题都有可能造成过瘦。

锻炼身体可能是个不错的方向，不过我有朋友健身房坚持了几年还是干瘦干瘦的，怀疑没抓到症结。

饮食上建议不要在短时间内有太大变化，身体可能会不适应，找到靠谱的方法，循序渐进。

得根据出行计划以及候选目的地的时节吧，泰国的话最近几个月貌似是最热的时候，马上就 3 月份了，可以去日本看樱花。

其实消费大头主要在机票和住宿，一万左右中国周边国家应该可以，发展中国家应该无压力，去发达国家可能会比较吃紧。

我觉得你买新品和你女票的 MBP2017 不会有多少差别，倒不如直接用她的。

你想想，你卖了女票的 MBP2017，买了一个和 MBP2017 不管外观、功能还是性能都几乎一模一样的 MBP2019，何必呢。。。我就是一直在用 MBP2016，而且觉得还能再用 2 年，我是做后端开发的。

用 Mac 基本就是冲着系统去的，而不管是 MacMini、MBP2017、MBP2019、MB，日常使用都是完全一样的。

JTW 实现无状态的思路是把用户会话完全交给客户端来记录，所以需要服务端修改用户的会话状态的话，JWT 这种机制就不适用。

不过拿 JWT 来当 Cookie/Session 来用也未必不好，比如能比较方便得解决 Cookie 在各应用平台上实现的难题。

没有银弹，每种设计思路都有适合或不适合的场景，如果想最大程度享受无状态带来的好处，又希望有改密码踢出登录这种功能的话，可以把用户密码的 Hash 也存在 JWT 的 Payload 里，然后如果有人修改了密码就把这个用户 ID 和密码 Hash 放到各个服务的黑名单里，比如 Token 失效时限是 7 天，那么这个黑名单里的项目也可以在加入 7 天后自动移除，这样在预期极少数人修改密码的情况下可以做到尽可能无状态。这个方案稍微复杂一点的就是如何在弹性伸缩的服务集群中有效广播黑名单。

都是要看实际情况来设计的。

@Laynooor
@zhaishunqi

调皮~

去世了就回来改一下文章内容吧，毕竟维基百科上也是发生了事件随时人工修改的。

其他的场合可能更合适，比如：“距离人类首次登月已经 XX 年了”。

Google play store 或海外 APP store，下原版。

逻辑分形式逻辑和数理逻辑。
数理逻辑是写程序用的，看离散数学就可以。
形式逻辑是和人交流用的，我记得是法律专业的必修课（一般大学里好像就叫逻辑学），可以找找相关教材

systemd 能满足需求

恭喜你捡到宝了，确实是万能的。
Arch 的两大法宝 ArchWiki AUR

@tg1108 个人认为回调处理异步本身没有什么问题，但是用在不同场景下可能会觉得不顺手，所以最好提供一些例子，表明在这些情况下有什么觉得别扭的地方，然后大家可以按此情况提供一些建议

之前认真研究过代码里的注释到底应该是用中文还是用英文，突出的问题是翻译难以信达雅，比如“ ArrayBuffer ”翻译成“数组缓冲”听起来好陌生，以及“地推”到底翻译成“ Ground Promotion ”还是“ Earth Push ”不管是老外还是中国人都听不懂，最终的结论是都不重要，重要的是让别人方便理解。

说话的时候也一样，重要的是让别人听懂，哪怕用纯中文交流还要注意大家是不是在同一个知识层面上，夹带英文词汇也得是基于同一个知识层面上。

所以我最烦人家在不清楚我是否知道一个概念的时候跟我说这个概念的英文缩写，比如“这件事的 I 非常重要”我怎么知道这个 I 是 ROI 的 I 还是 KPI 的 I 还是 RACI 的 I ……

@chaleaochexist
首先得确定业务上的 resource 越来越多的原因是什么：
1. 程序规划失误，该删删，该合并合并，特别是已经废弃的业务，保持代码精简。
2. 产品无理需求，该拒拒，改怼怼，或尝试帮产品经理梳理需求得出更简单有效的方案。
3. 实际业务规模扩大，这时候就无法避免 resource 的数量上升了，横竖业务复杂度就那么多，View 层再怎么精简只是把复杂度甩给了其他层；如果 View 层 resource 太多造成复杂度过高，那么可以依然使用分层解耦的思想来解决，继续拆分，比如微服务和 BFF(Backend For Frontend)。