居然单级时间轮就够了 ...

对了，说起游戏，最近倒是有个不完全的反面例子：Google Stadia

国内外评价一致扑街。
不过之所以说是不完全的反面例子，因为很明显这东西国内用不了 ...

解释下楼主观察到的几个现象：
”其它游戏质量不怎么样“ 任何市场都是精品占少数，平庸的占大多数。而人的平均认知能力是恒定的，Steam 上十几年积累了很多的精品，数不过来，不会注意不好的部分，Switch 是小市场，尤其 17 年才出来又没有向下兼容，对于同一个人来说显得精品少（给人感觉除了那几个之外就没了）
”Switch 溢价“主机游戏都这德行
这两点都不构成批评 Switch 的理由
我倒是认为，整个”主机“就是历史遗留的旧势力，早晚会被清扫出去。Switch 相对于 PS 和 Xbox 还算比较有特色的了特别地，PC 可以部分替代主机，但是手机对掌机的替代性不足（还是一个可以接电视的掌机 ...），所以目前 Switch 没有实际的竞品。如果你把 PS 和 Xbox，Intel 和 AMD，NVIDIA 和 AMD 这种 duopoly 绑一块看，它们也是没有竞品的，而这些 duopoly 内部竞争也不足（牙膏厂：呃 ... 竞争 ... 不足么 ...）
碰巧楼主说的 AirPods 也是没有实际竞品的，但是不仅仅是没有竞品的东西能吹，竞争激烈的领域也能吹——参见 HiFi 圈 ...

另外，主机本身卖的就不是硬件（虽然家用机光裸硬件性价比看上去还可以），卖的是信仰，情怀，或者更广义地说是卖故事。

媒体方面，我们先排除厂商塞了钱这种可能性（虽然就”国行出来之后更是如井喷般地出现推荐文章“的情况来说不好排除 ...）。
一般专门做一个领域的都是有这类爱好的，本来就是什么新鲜就买什么，稿子写完了就扔一边做新的评测。这样”有时还可能外放“这种问题很可能不会显现出来，或者就算是”长期使用体验“，对于评价的人来说，产品解决的问题（哪怕只是满足了新鲜感，情怀或者跟风需求）远大于可能的问题，就不会把问题当问题。
同时也不要指望大多数”博主“能给你整出什么专业的东西，比如电子产品，真要”专业“起来需要大量跨领域的知识，真有那么牛的人也不会去做媒体（就不说写出来的东西大家看不懂了，现在”博主“们写的东西很多人理解都有障碍），”博主“们只能边做边学点皮毛。

至于个人评价，个人就只买那么一点东西，并且少有横向对比的机会，最重要的是会有 justify 自己的购买选择的倾向。
我举个例子，比如我现在回复用的 HHKB，如果我写评价我会更侧重于”皮实，小巧，键位没那么沙雕“，至于缺点呢，比如键位很奇葩，我会说”HHKB 的键位对于重度 Vim/Emacs 用户十分友好，对于 Mac 用户也比较友好，在我的场景中可以做到基本不使用方向键和 Function Keys，简洁的键位使得键盘在好用的同时保持最简“，比如不能全编程，我会说”作为一个程序员，我一直认为依赖于硬件提供这种简单的能力是非常落后的做法，应该有一个统一的软件层来对键盘操作做更强大的抽象“，我这个还是有线版，我会说”我不会选择蓝牙版 HHKB，因为在台式机上使用需要额外的蓝牙适配器，并且我之前的蓝牙键鼠使用体验并不好，稳定性很差，而且蓝牙键盘必须在进入操作系统之后才能使用，BIOS 中无法使用，在调试相关问题时基本没用（特别我还是个 LUKS 用户，配置解锁硬盘时使用蓝牙键盘很麻烦），没有有线接口的蓝牙版 HHKB 除了溢价之外什么都提供不了“
你看，缺点都能吹出花来，还不失专业性。讲真要是要我说有什么缺点我还真说不出来，因为我发现它的特色我适应了，它没有的东西我不需要，真用着不顺手的地方（比如我到现在数字键没法盲打）对我也不算什么大问题。
这也说明了很多时候”缺点“不是绝对的。

从动机上来讲，做评测的人不会在每次评测中给你重复”你应该先考虑是否有需求再考虑购买“，他只会给你讲产品本身的特色。
另外楼主说”其它同档次的分体蓝牙耳机“，说实话我还真反应不过来有哪些”其它同档次的分体蓝牙耳机“。甚至我觉得这个市场除了苹果和索尼之外的事情根本无人关心，一个媒体如果不做这两个品牌却主打别的同类产品倒显得奇怪。大品牌本来就会建立优势，就算你不想买苹果和索尼，你也会发现剩下的里面很难挑，那干脆不挑了，就买苹果 /索尼了。
大众媒体的评测就更别看了，这类东西一般受众面更广，也更不专业。

小国和小国有矛盾，联合国一调停，矛盾没了。
大国和小国有矛盾，联合国一调停，小国没了。
大国和大国有矛盾，联合国一调停，联合国没了。

你们怎么都 assume 是楼主要去购买装系统服务

没准是楼主看看行情想要转行开电脑店呢

不如老哥们把上面那位激一激然后举报了吧 ……

@nyanyh 你 check 下代码，你这个“prtToPair”看起来是个 MyCombo * ...

U 盘本身就不靠谱
没有靠谱的存储介质，真靠谱需要多份备份+checksum

试试用 #3 的方法加上 #2 的 HKT

template <template<typename> class A, template<typename> class B>
struct MyCombo {
typedef A<MyCombo<A, B>> a_t;
typedef B<MyCombo<A, B>> b_t;
};

Aa<MyCombo<Aa, Bb>> a;
Bb<MyCombo<Aa, Bb>> b;

搜 variance
另外这个不叫”子类”，subtyping 和 inheritance 不一样

@nasmatic 你需要看大量的 hinative，wordreference 和 stackexchange 才能有初步的理解，并且不同人给你的解释不一样。就别说 hinative，wordreference 和 stackexchange 也有大量对词典的引用，也就是说很多”本地人“在解释的时候也出现了主楼所说的”说不清道不明但你又很难用错“的情况，而这个时候最普遍的 fallback 是词典。
相比来说，词典（主要指英英词典）在极小的篇幅中压缩了极大的内容（这也是词典本身的目的所在），只是读者能不能理解的问题
（你以为英英词典就不是本地人写的了 ...

原因就是词典就是对语言在应用中的经验再总结沉淀为理论的产物，相比于经验来说是更加 higher order 的东西。hinative，wordreference 和 stackexchange 上这类问题的大牛的终极形态是一本人肉词典 ...

我来 generalize 一下楼主的”感悟“：
很多你以为的”技术问题“其实不是”技术问题“而是”经验问题“

扩展：人们是尊重经验的，但我觉得人们更偏向于能把经验抽象为理论（也就是沉淀到”技术问题“）

就楼主的这个近义词问题来讲，我觉得目前词典是做得最好的

楼主这个统计的精神可嘉，但是干不过小屏手机在市场（尤其是 Android ）事实上已死的现状
就像我也有个类似的 CPU/GPU 统计，统计的结果是没一个能买的（嘛，大概 2191B 除外 ...）

”小屏“当然就是指”小屏“啦，不是指正面面积小，是屏幕面积小，正面面积小但是屏幕面积不够小照样没法单手操作（主要是屏幕太长）
”正面面积小但是屏幕面积不够小“（或者”年前对于小屏手机的定义是 5 寸，而 2019 年，把 6 寸以下手机定义为小屏机“）的原因是”全面屏“的普及。但是这个”全面屏“怎么做可大有门道
Apple 把 iPhone 8 的屏幕尺寸不变，额头和下巴切掉再加个刘海算是”全面屏“，Apple 把 iPhone 8 的整机尺寸不变，屏幕放大再加个刘海也是”全面屏“。但是前者还依然能算是”小屏“，后者就不那么”小屏“。（事实是不仅 Apple 走了后者，”全面屏“后的 iPhone 长宽高甚至都又大了一圈 ...）
”全面屏“之前的很多手机在屏幕左右的边框上已经做得很窄了，”全面屏“概念上主要是消除上下的边框（实现中是通过放大屏幕来消除边框），但是对于”小屏“来说，上下边框有多宽其实根本无所谓，他整个 3 cm 的下巴照样是小屏。

你的第二行其实可以归到第一行里面 ...（前提是你在做第二行时没有消费行为）
现实就是 996，以及 996 升级到 007，你只要没有在为社会主义现代化建设做贡献，你就是在逃避现实。

和楼主不同，我认为人类作为一个物种，最伟大的地方体现在这个网站以及它所提出的设想：

http://www.vhemt.org/success.htm

> We’re the only species evolved enough to consciously go extinct for the good of all life, or which needs to. Success would be humanity’s crowning achievement.

> May we live long and die out.

这个硬件厂商玩了好多年了已经 ...
有空多看看 AI 界和医学界大佬 Jensen Huang 的演讲，买买他出的书和课程，支持一下他的燃气灶业务

当然有替用户考虑的成分，Web 技术本来就不适合开发应用，大多数基于 Web 的应用的效果也就那样。禁止了 Web 技术在应用中的滥用，用户的使用体验更好了，续航更长了。
也当然有替开发者考虑的成分，对 Web 技术的限制会增加对 Apple 平台原生开发者的需求，Apple 护自家开发者的犊子，消灭投靠 Web 的异教徒可以理解。

但是我不看好这种用简单的技术手段解决非技术问题的尝试。
iOS vs. Android 的根源其实是个千年老问题：管理者该管多少合适？“自由”的边界在哪里？

@murmur 我的理解，Apple 此举的主要目的，通俗地说就是禁止热更新（应用送审后行为不能改变，或者说与外界通信内容仅限于数据，不能传输程序）。
还有一种可能是遏止非原生框架（包括“H5“）的大量使用对体验的劣化，不过我个人偏向于前者。
所以理想情况应该是封有热更新行为的应用，但如 #48 所说这并不现实。之所以单独拎出”H5”，以及专门扯了一堆 WebKit JavaScriptCore 之类的，是因为使用“H5”和热更新这两者之间有一种奇妙的强关联，基本一抓一个准很少有错的，事实上就官方声明来看已经对“H5“采取了一刀切的手段。

但是我不认为所有类似的跨平台框架都在 Apple 的目标之内，因为”跨平台”和”热更新”根本就是两个正交的需求（虽然可以用同样的技术手段解决）。跨平台框架可以不做热更新。并且理论上，跨平台框架也可以做到把所有东西塞到一个 binary 里面（只是目前可能还很少这么做），至少可以满足技术上的要求（不运行 binary 以外的代码）。
“热更新”（或者广义上的执行非自身 binary 中的代码）也不是禁了已有的框架等具体的技术就能禁的，因为“数据”和“程序”其实是无法区分的。甚至一个程序有没有“热更新”行为也很难界定。

最极端的情况是有实力也有需求的大厂自己造私有的跨平台 /热更新的框架。想到这最搞笑的是，如果真有人用这种方法绕过热更新限制，那就没法做 JIT 的现状和某些华而不实的大厂的真实水平来看，可能最后体验还不如 H5