草，一坨错别字……
“源码反码补码”→“原码反码补码”
“几乎所有体系结构都要求机器数用反码”→“几乎所有体系结构都要求机器整数用补码”

@abcbuzhiming 结论上我同意这位说的。
不过到这个份上，所有在这楼里提到问题的其实还只是冰山一角……能只考虑单一项目的问题而不是更长期的副作用，实在是很幸福的了。一方面，做项目会遇到选型问题；另一方面，维护个人技术栈也是很坑的。
虽然和主题没有直接的关系，我在这里想多补充一点生态而不是方案上的牢骚：造成现在的混乱的原因，虽然算不上是有意的，但过于放纵 naive 的 native 方案的开发者多少都有历史责任。
首先，业界公认的一些基础方案的可移植性实际是非常强的，远远超过在个别指定平台中选择可行方案的跨平台需求，但欠缺足够多的用户去鸟，造成形同虚设，还要在标准化上倒贴维护成本。
像 ISO C 从一开始就强调 portability，强到了绝大多数应用开发者匪夷所思的地步——比如 CHAR_BIT >=8 （ 1 字节可以大于 8 位），比如整数的表示可以源码补码反码之一，比如 '0' ~ '9' 执行字符集要求编码连续但 'A' ~ 'Z' 就不是……
一方面这些差异因为几乎从来没什么开发者去纠结而默认了—— POSIX 和 Win32 以及常见体系结构都钦定 1 字节 = 8 位，几乎所有体系结构都要求机器数用反码，除了 IBM 的某些异类都要求 'A' ~ 'Z' 的编码连续……这样的一个结果就是大多数 C 的开发者其实只是使用了一个较弱可移植性的子集。而 C 的层次上，因为提供了这样强的可移植性，对实现的约束就非常弱，所谓 strictly conforming program 几乎就没什么实际的活能干。其实 C 的用户在这个意义上已经分裂了，绝大多数的人都在用 GNU C、POSIX C 或者 Win32 下的 MSVC 方言，外加一票嵌入式平台的魔改方言。另一方面，ISO C 又不可能把这些方言都吸收了，因为这削弱可移植性，跟 C 的设计者的意愿就有冲突，也会引起不同厂商之间不可调和的矛盾。这就是一个长期没人能解决的两难状况。
ISO C++ 因为 C++ 的复杂性这样的一坨屎的情况，比 C 总体好得多（虽然 C++ 的乱加特性还导致另外的问题），比如干脆直接回避了 strictly conforming program 的概念。不过大部分 C 的可移植性包袱包括用户脱离语言 spec 的认知的问题也还是继承了下来（如大部分用户可能都不知道直到 C++20 才刚刚要去除除了补码以外的机器数的支持）。这样长期下来的结果就是 C++ 和 C 用户一样具有强烈的碎片化倾向，而标准语言长期不够用又反过来让不可移植的小圈子扩展更加猖獗继续加剧碎片化（如 Qt 的 moc ）。加上非通用工具使用经验的依赖，进一步大幅提升招人的成本。
对关心以后业界发展的生态用户来说，这一直是两难问题。一方面不能否认 Qt 这样的（相对标准 C++ ）半吊子扩展方案确实解决了标准语言不便搞定的不少问题；另一方面，越是依赖 Qt 这样的方案，越是没有办法阻碍分裂，以至于以后越来越不可能有标准化的跨平台方案能用（直接的原因：人员和工具成本越来越高）。
所以在选型的立场上我也是两难的态度：一方面用 C++ 这样的基础方案本身已经在承受无法彻底解决问题的困难；另一方面，足够大的项目中不去用 C++ 这样的单一基础方案而分别重复造轮子的选项，多出来的开销迟早会让你无法自拔。
WG21 已经认识到这里的问题的严重性了，所以才强推不适合在语言 spec 里搞定的 module 之类的东西，以便加强 tooling。不过技术上这种强行乱来我是不看好，该无视的还是无视吧。
（至于 C/C++ 最终是靠什么才在一片混战下活了下来？山中无老虎猴子称大王+历史包袱。）
其次，有不少大企业想建立生态填补这里的矛盾，但实际上技术上都失败了，败给了 C/C++ 的历史包袱。
考虑现在应用的技术栈，操作系统（是个大坑）先不提，光是运行时的实现，只要有些定制需求，就不可能彻底甩脱这个包袱。比如，各种服务器语言的运行时不是 C 就是 C++ 实现的；最终用户碰到的 web agent 几乎无一例外都是 C++ 实现的。结果就是你逃离 C/C++ 完成常规的开发基本还算可行，但一旦要“调优”，就得多少储备这些实现上的细节。然而运行时基本都不是自己开发的……谁能保证这样的任务总是能够被解决？（于是有的企业干脆就自己定制语言实现了，但还是一种循环。）
好在大部分项目在接触到这个坑之前，业务上可能就已经自然死了。但万一没死……恭喜你又制造了一坨业界历史包袱……
苦中作乐的话这也不全是坏事：恶心的屎全归结到 C/C++ 以后，C/C++ 就是屎的事实上的金标准，甚至在没有具体厂商撑腰的前提下就可以避免 vendor lockin。比如听说某果想仗着 ObjC 搞垄断？没关系，你 ObjC 糊弄多少新的开发者也没 C/C++ 的历史包袱和群众基础，只要能糊得上，就算没 native 程度的支持是会恶心到大多数开发者，但谅你也不敢彻底不支持，否则就是自寻死路。（相比之下，web 自己作另说，搞图形学什么的就有点惨了。）
最后，作为历史包袱的受害者能怎么做？
横竖都不咋地，如果没法改变所谓的生态，自求多福，祈祷不会遇到意外吧。
如果谁真能在业务以外实际推动跨平台的实践，我姑且代表个人表示感谢。不过我是真不太信整个蓝星人都不太搞得好的问题，一般人能不添乱的。能尽量别依赖并且能适当抵制不靠谱的半吊子 native 方案就不错了。
请量力而行。

@cyxcw11 理想情况下，C++ 的技术优势是一坨屎。重复重点，“一坨”屎。因为这种涉及移动平台的开发普遍缺乏标准化，基本上你用几个 native 方案就是几坨屎（语言、框架甚至开发工具都不怎么通用），充其量就是比 C++的屎小那么点；但只要是超过一坨，工程上的复杂性就超过一坨两倍以上；而且因为可以公开使用的资源可能不够丰富的问题会恶化；实际要正经考虑跨的平台不止两个，那就经常不止两坨；种种原因综合下来，高下立判。
然而非技术问题上的渣滓对一般来讲更麻烦。首先，C++ 糊的屎的粘度经常不够大，就算是自己造的，不专门安排人去“优化”框架本身的话，一不小心就散了，结果碎片化方案的数量上比直接用 native 的更恶心。然后，C++ 的用户素质比起现有 C++框架方案设计本身普遍还要低下，你招得到能 hold 住现有方案的人，那就是在赌脸。
和 @xsen 说的有点不同，这里 hold 住还不够，要保证框架维护人员能跟得上产品生命周期，否则万一人员流失交接起来会非常困难，规模一大会很快没法收拾，于是其实还得有足够强力的备胎开发人员才安稳……所以实力不够养的起闲人（乃至自己搞整个跨平台方案的）项目组基本就只能被迫放弃整坨 C++ 屎了。
尴尬的是，有些地方现实可行角度上还是非得用 C++ 不可，于是流行 C++ 写这种不得不用的所谓“关键”模块。所以你会见到这种大杂烩，其实就是工程上的妥协。（另一个角度上说，真能强行拿 C++ 硬肛的那确实算是有点实力的，虽然经常不能算是经济上的最优方案，质量也经常不咋地。）
而具体妥协的效果能怎么样，真没法一概而论，不光和人员素质，和开发内容（比如说现实不得不用 C++ 的模块占比）也有关。你还是得问问你老板能给多少预算和承受多少项目失败的风险再决定。
再具体来讲，如果你是要开荒自己造平台甚至造生态，那么一开始就上 C++ 之外，基本没什么别的选择（除非你自己能花几年做出汇编器编译器之类的全套工具链，像 Chez Scheme + Racket 这样；至于 C，会搞这个的更难找，别多想了）。
而如果只是要开发应用，那么方案余地会松一些。特别地，只限定 Windows/Linux/macOS/Android/iOS 这几个常见平台中的个别几个的话，可能还有不少别的选择。只是很遗憾，现时如果你打算通吃这些平台并执意避免分别重复开发不同的 native 实现，现成的方案里大概可能就只有 Qt 能马上上手——效果看着办，不大容易比用 native 的好。
关于 Qt 多提几句：
1.开发新平台的话，要是不考虑成本没项目周期限制，自造的肯定能有更大的余地。定制 Qt 是小的嵌入式平台的备胎选择，理论上确实也算是 Qt 的卖点之一，实际上嘛，呵呵……
2.话说回来，Qt 的 GUI 其实还算 Qt 里质量相对过得去的（尽管其实现的绝对质量不咋地，GUI 实现这部分隐藏了尤其多的外行人难以摆平的恶心的细节，相对质量一般总比临时赶工自己造的轮子好），所以要用 Qt 放弃还里面的 GUI 某种程度还是有点浪费的；而只是做业务框架，其实并不见得比有经验的自己搭框架好。
3.QtCreator 是能用，但主要只是跨平台统一环境有优势，实际体验谁用谁知道。如果你是 PM，建议别限制开发人员的环境（反正都跨平台了……）。同时，对上规模的项目，为了分散上游选型风险，需要考虑采取措施避免过于依赖 Qt-specific 的（特别是和别家 C++ 习惯都太不一样的）技术。
（我现在没维护多少用 Qt 项目的代码，但我为了自己造能代替 Qt 的备胎，主流 C++ 框架多少都看过，而且改过若干 W 行用 Qt 的开源代码自用，所以可修改性问题有多屎的参考意见……看着办。）

说是宇宙第一，VS 作为 IDE 的 UI 上小毛病不断，其实屑得很。以小见大：一个升级插件的界面居然用模态对话框（最近才改成升级，还是要重启），被 eclipse 都打粗翔。（当然 eclipse CDT 的别的体验有多烂我就不多婊了。论字体渲染倒是可能吊打 NetBeans。）
至于 j8 家的东西，以前在我的几个实例上经常有跑不动的，正常构建流程出问题的（ Android Studio gradle 卡墙先不管，响应那是个屑）甚至还有打不开的（当年的 CLion ），外加 VS 装.NET Reflector 日常直接卡翔加成 200%的。这类目无交互式程序响应需求的破烂，当 GUI app 就不合格，当然就什么没资格当 IDE 来讨论了。（当然，Java 撸的客户端嘛，整个都是……）

@missdeer Qt 这个项目技术上最大的毛病和其它类似 C++ 项目的毛病一样，就是把用户搞傻了，框架设计人员自己本事又不到家，以至于各种选型都是次等货色，还居然被社区稀里糊涂地接受了。
（什么 moc 就不婊了，那啥 qmake 啊 qbs 折腾了多少时间又滚回 cmake 这种半吊子……不安分老实 autocrap+make，或者搞个类似 xmake 的会死？）
而且基本上 Qt 的用户是没本事推翻 Qt 框架设计内部缺陷和拾人牙慧的问题的。小 bug 多也很自然，因为就没几个有本事一开始就尽量避免小 bug 的开发者有耐心对付这个陈年破烂。
然后不用 Qt 的 C++用户某种意义上还分裂了……（虽然这主要不是技术问题。）

不扯 UI，一切好说。摊上几个奇葩的平台，基本上你不用 C++也没什么备胎能选。原生？能接受哪天突然发现某个原生 API 不够用或者政策出问题不给用了缺胳膊少腿也行，否则省省吧。
UI 的话，Web 的实现本身依赖 C++。别的你要是自己没把握撸整个平台的话就算了吧。

LZ 是不是对易用性的理解有什么奇怪的偏差？都直接拿来折腾了而不是供应商担保的整机解决方案，驱动兼容性问题能算哪门子的易用性？
不说年代问题，每个版本的 macOS 就适配几个 SKU，一个 Windows 要适配几个？
本来就不是一个级别的东西也拉过来比较，真是醉了……

@permaylau 可以带号转手啊。要是卖号还卖不过津巴布韦元，那也太失败了……

另外 @no1xsyzy 说的肌肉记忆和我说的不完全是一回事，那种依赖的视觉反馈的更高级也更难形成，这个和个人习惯也有关系。总体来讲，这比输入上的肌肉记忆更偏向于实现，并不那么人人适用，只是根本原理是一样的。
对我来说，我首先会把阅读代码时的存在的 { 和 } 之类的标点在视觉上垂直对齐这类情况训练成“肌肉记忆”，因为这在确认块对齐的时候非常明显地提升时间效率。这也是我不想看非等宽字体写的代码，以及非常厌恶 {} 强行不对齐的代码风格的原因。
此外，我排斥被动的肌肉记忆：如果能不记忆，那么最好没有。像 begin 这样的记号（而非自然语言意义上的单词）实际上在语法(syntax) 而不是文法(grammar) 上就是固定的，begin 和{的视觉差异是先天显著的，我会在效果上要求我使用的语言有{的直接支持而不愿意去读写 begin 再自己脑补#define begin {这一条记忆规则。自己去形成 begin 映射到{肌肉记忆会浪费记号编码空间和浪费视觉的带宽，更令我更不爽的是其他人写的代码还是写 begin 而使我被迫去做这种无用功的事实——明明是某些人自己没搞清楚 { 比 begin 的普遍特殊在哪而根本不值得让人去 #define，偏偏这些人中的一部分无知者还大言不惭 begin 的所谓“可读性”比 { 更好，也是醉了。这种情况下的被动肌肉记忆实际上体现了输入质量（代码和促使代码这样写的语言设计）的恶劣（所以光是这一点就不喜欢 PASCAL 和 Lua 之流）。相比之下，使用 QWERTY 键盘的肌肉记忆，就算能用别的方案去替代，基本上也就是用另一套肌肉记忆而已，省不掉的，所以就不用这样纠结了。

@myfei 麻烦你自己先理顺逻辑。
输入代码和理解应该什么代码能一定程度上并行，这是常识，也是讨论这里的问题的前提之一。这个前提下你说的很多东西本来就都不需要在这里考虑，然而你非得硬放在一起，那只能多说几句了。（而且这不是我一个人的意见。）
另一个前提是你提过的，输入在这里一般不会成为瓶颈。这个结论没问题，我也同意，但按生理常识，严格按你声称的实现方式（同步操作）和这个结论有矛盾。所以我还得多指出你这里的问题。
上面的几个问题和中文不中文变量名是没多大直接关系，但跑题很大程度是你引起的，你得自己绕回来。
生理活动事实上如何，最粗浅的部分你自己就应该能感知得到，验证起来应该不费吹灰之力，我是不懂你能如何不懂或者强行能得出相反的结论。
至于肌肉记忆，我可没说能代替理解。能肌肉记忆的仅限输入过程中的很小的一部分活动，但已经提升了显著的可并行性，因为严格按你说的同步实际上就是极慢的。我提这个是作为结果这应该无关紧要，但是想要排除就是不现实的。
其它工作也不是同等费时的。像选择 API 之类虽然不是肌肉记忆，但熟练起来可以提升的空间很大，和肌肉记忆依赖熟练度倒是有一些类似的地方。对大多数人来讲，真正怎么都慢的是如何设计解决方案这样的没有经验先例可循的业务问题，这不可能靠肌肉记忆或者经验担保效率总是能够提升。而到编码阶段，不熟悉要用的 API 这样的场景才慢，但慢主要是评估确认 API 的活动（包括看文档），也不是选择具体 API 这样的思考。
相比之下，分辨哪个变量是哪个这种问题，比选择 API 和判断效果是否能够达到目的通常更快。你非得把变量名写得奇怪和带有误导性，会让这个活动更麻烦，但也就是麻烦，一般不应该花费更多时间；没法避免这种情况就该考虑撂担子不干了。像你说的几十个变量名里面选择一个这样的情况，除非这是业务逻辑的一部分（比如设计中就要求这么几十个名字里挑东西），也不应该是最慢的一类活动。如果这个已经成为瓶颈，大概是要检讨设计了。

所以这些 CS 导论就该明确方向的系列问题怎么还那么经……
还是得从基础概念入手。
https://stackoverflow.com/a/51759235/2307646
里面引用的 Robert Harper 的博客文章看来又能点进去了，那就不重复为什么需要这样明确之类的细节问题了。
就说重点，补课，再解释顶楼的问题：
1.并行(parallelism) 和并发(concurrency) 都是计算（或者说，表达计算的程序片段）的性质，但两者本质上是两回事。
更进一步地，两者可以是正交的：程序中并行和并发程度的多少之间也没有必然联系。
注意，计算是抽象的。计算的实现，包括“同时”之类的物理属性，和这些性质没有直接关系。
2.并行是关于管理程序中确定性的(deterministic) 计算之间的依赖(dependency) 使它们整体具有更好的渐进效率(asymptotic efficiency) 的性质；并发是关于处理程序的各种非确定性的组合(non-deterministic composition) 使之能响应各种不保证可准确预知的时机输入的性质。
一定程度上，不考虑依赖之间的动态变化，并行描述的是程序中的计算之间的静态关系，而并发可以描述不确定的动态关系。
3.并行的对立面是串行(seriality) ，指一系列确定的计算明确具有链式的依赖；并发的对立面是序列(sequentiality) ，指不确定的计算的某个子集之间，其顺序被约束了。
约束计算的操作称为调度(scheduling) ，其中可能包含对计算资源的分派(dispatch) 。
4.进程(process) 或者线程(thread) 为了实现是占用特定的计算资源完成的带目的计算（或者说，任务(task) ）引入的抽象，是程序的动态映像和为了实现计算分配的其它资源的集合。
两者的区别传统上和资源的具体集合有关，这里不是重点，以下都以可调度的线程代表。
作为组成其它程序的组件，它们可具有并行和并发的性质，分别通过竞争性调度机制的具有非确定性和调度中分派计算资源的目标不同的事实而体现。一般地，决定如何调度的逻辑是在进程或者线程之外的。程序通过这样的抽象的表达，只是表明计算已被拆分成为不同的待调度的组件，并不能保证已经具有并行或者并发的性质。
5.使用进程或者线程这样的抽象只是为了便于实现这种特定的可调度的计算表达。
这不排除其它手段实现并发和并行的手段，因为一般情形下，调度自身的效果被不确定性涵盖而不是计算的作用(effect) ，不被要求对用户可见。最简单地，一个表达式在计算时若不要求子表达式计算之间的相对顺序，也没有影响计算结果的依赖限制它们之间的顺序（以保证不违反计算的因果性语义），那么它们的计算原则上就是并发的——用户没法预知确定的计算如何发生，也没法保证确定这里是不是需要插入一个线程或者其它可调度的实体来实现并发；而若使用确定的最优化规则（例如某个指令集允许的指令级并行规则），它们之间也可以是并行的，用户可以查看目标代码等方式来确认这里的计算被分派到不同的设备上同时实现以取得比串行计算更好的效率。
6.为了解决共享资源的竞争引起破坏计算的目的非预期的非确定性，可能需要引入同步。
同步操作和调度一样约束计算的顺序，因此可能有相互作用，例如增加不必要（程序中不要求表达）的隐含依赖而减小程序的可并行部分，并最终实际减小并行程度。
就 LZ 的例子，GIL 是一种粗粒度的内部调度机制，在极端情况下把并行语义的程序串行化。这个意义上它是不并发的，但这是偶然情况，不是实现系统总是对用户可见的整体的性质，更不是语言要求的性质（ PyPy 就不用 GIL ）。
7.多线程中的线程在不同的上下文中不严格地是一回事。
一般地，高级语言使用表达式的求值引入计算的作用。对大多数高级语言来讲，默认情形表达的计算遵循同样的顺序规则，最常见的如指令式语言按程序的字面顺序(literal order) 。这个顺序整体上约束了确定性计算（尽管按上面的讨论，像子表达式这样的计算仍然可以是非确定性的）。
为了更明确地表达可被程序操作的非确定性计算，同时不修改默认情形的计算顺序的语义，按原有规则的计算任务整体被抽象为一个执行线程(thread of execution) 。多线程环境即指语言允许程序蕴含多个执行线程，每个线程内都适用默认计算规则；而线程间是没有类似的计算顺序规则限制，需要再另行约定共享计算资源和同步操作以明确线程之间计算的互操作。
这个意义下，“同时”或者竞争调度不是多线程的关键。尽管语言中的执行线程允许并发，但不可见的调度实现不需要提供计算资源是否在物理上（同时）被重叠利用的保证。极端地，调度可以完全放弃对线程的资源分派，无限等待线程自发完成计算，此时线程不再抢占(preemptive) ，调度退化为协作式多任务(cooperative multitasking) 的实现。
但大多数情形在语言引入执行线程的目的不止是为了允许在程序中表达非确定性，还同时作为提供显式复用计算资源的特性（乃至显式地并行），所以不太会有这种调度内部直接放弃非确定性退化成平凡情况，执行线程在这里也就和一般意义上被实现调度的线程不加区分，统称为线程。
存在 GIL 虽然更接近退化的情况，只要不改变被实现的语言具有多个执行线程，且语言不能绕过执行线程可见地调度线程，那么整个实现就是一个多线程环境。
8.在硬件实现中，因为在外部看来计算资源整体的占用是很大程度上能预期上限，习惯上把这部分实现可用的资源（特别地，一个 CPU 核）作为一个物理线程。相对地，一个能被软件分辨并调度的线程是逻辑线程。
同时多线程(SMT) 专指这里的复用物理处理器核的硬件资源，以使一个物理处理器支持超过一个逻辑线程的手段。在软件看来，一个线程逻辑上对应一个处理器，因此一个物理核心对应多个逻辑处理器。
不支持 SMT 且只有一个物理核心的实现仍然可以通过分时复用实现多线程。这和软件的语言实现的情况类似，因为物理核心原则上对软件不可见，所以软件的意义上这就是“真正的”多线程。
9.硬件相比软件的特殊性是可提供物理同时的多任务支持：一个处理器 package 可以有多个物理核，如同一个抽象机进程中支持多个执行线程，这似乎符合最朴素的抽象。
但这和并行或者多任务根本上都没有实现以上的关系，因为如最开始提到的，“物理同时”从来就不是考虑这些抽象时必备的要素，仅仅是方便理解而提到罢了。
而且，实际的处理器内部也不可能完全重叠地利用计算时间，最显然地，要求时钟同步来避免非预期的不确定性。
此外，单一核仍然能通过异步中断能实现物理上同时的多任务，这和多线程也没有直接的关系。

@myfei 生理上“写代码”就不可能是完全同步的操作。你所谓的同步，是逻辑步骤之间的顺序性，这不影响身体的不同部位能够并行，自然有条件并发。
如果你非得把注意力来回集中在手上，那手动一下每次同步都有几个毫秒的神经传递延迟，加起来是不是至少有一半时间你脑子都不用干活了？况且正常人不刻意做根本做不到这种严格的同步。
退一步讲，不严格的“全神贯注”单工操作也是一种低效的方式，因为至少在注意力集中在理解代码的时候，手在物理上也是不必要停下来的。明明能做到（有限地）并发，为什么强行要（假装）顺序操作？
看到你笑了我就知道你不擅长用键盘输入，至少是不擅长大多数人原则上都能学会并的输入方式。像 QWERTY 这样的键盘布局，本来就刻意避免什么固定的含义，因此正常人高速熟练输入之后是没理由时常去盯着刚刚摁过的键位发愣的；结果是对按键词频的感知是无意识的，但又不会立刻全部遗忘。特别地，像 pre-/re-/init-/-tion 之类常见双手左右开弓几乎并行输入的按键组合，输入几乎不过大脑基本上也不会出错。这就是一种肌肉记忆。
写代码当然不需要首先强调输入有多快，但这个快就是指吞吐量；如果影响响应中断思路，那么实际上吞吐量再大也是慢的，这种影响应该越小越好。就算这种情况平时不怎么遇到，在一瞬间成为瓶颈也是不爽的。如果你从来没有这样的体验，恐怕是你没有尝试处理过极限情形，或者你的脑子一向转得太慢而从来不考虑这样做了。
你所谓的不输错，那首先要求是盯着屏幕取词，跟用来输入的动作没有直接关系；真要有关系，那也是输入不需要经常性劳烦大脑，减少打断思路的机会能让注意力集中在这种输入以外的地方，那也能更高效。

@lagoon 医药费出了，人没救活，不行？
天王老子就是想要告诉你天经地义的解释权不归你等通行俗钱的下人所有。

@openbsd 扫地机器人、、、可能上面还能跑 BSD，，，

能自己写几行代码解决的事情，你还好意思抓几个人来替你搞来给老板添堵？

@hoyixi 35+的人好哄，还是刚出学校的小年轻好哄？
到时候吃了一堆房子的银行的窟窿便宜，还是让某些人仅仅吃饱饭便宜？
……上面有人所谓的奶头乐，实际上根本没起来，“前景”还大得很呢。

@hantsy 系统性金融风险那是明摆着的。
996 最主要到底薅得是谁的羊毛，很多人到现在都没搞清楚。