刚买的 Quest 3 ，也用过 Quest 2 。
单说 Google Earth VR ，进去稍稍体验了一下，地面比较模糊。交互倒是有点意思，但是也抵消不了缺点。
Quest 3 最大的升级是镜片，体验就是几乎全视野高清，Quest 2 只有视线中心是清晰的。（不排除是我 GTX 1660 Ti 性能差）。这就能满足我现在常用的场景，其中很大一部分是躺在床上无线连电脑看视频或者看 YouTube VR ，至于玩一体机 VR 游戏和连电脑玩 VR 游戏就不用说了。

Sony 21:9 看电影爽歪歪，上下滑长内容也爽歪歪
不过太长了单手略微不好操作就是了

@sunny2017 买的 100 支的多少钱，四件套少于 500 不行。
最近双 11 ，60 支的四件套至少 250 块，这只是最普通的长绒棉，密度 200x98 。不过我捡漏了，因为是旧款，只有 180 。还是很绵密的。
当然了，高支的不一定是喜欢的手感。或许你喜欢法兰绒、牛奶绒之类的手感呢，这类比较便宜，但是材料性能可能不如全棉，比如抗菌性能、透气、吸水、防静电什么的。

一直用 Sony 。Sony 现在已经不会丢失 DRM 算法了，再者说，自用保持解锁状态，也没机会用到。
至于相机难用。。。对于专业的人来说可能反而算是好用。现在系统相机已经不是 Google Camera 了，而是 Sony 自家的 Photography Pro ，能切换专业模式。
不知道 Xperia 1 v 发热怎么样，1 iv 的发热真的是。。。用一会儿手机就烫，性能就降低，app 后台退出，UI 卡顿。

我原样复制你的，能找到。语法也没问题。
你确定你用的是你贴的命令，而不是 --regexp ？另外你用了 updatedb 更新过数据库？

一直在用 Sony 港版，从 1ii 换到 1iv

less 的话要用 --UNDERLINE-SPECIAL 选项

cat 也会渲染成空格呀，用 --show-tabs 会改为渲染成 ^I

@ViolaH 我贴膜，膜碎了，我不贴，屏碎了。就这么简单
你不要说我瞎猜，都是亲身体验

根据劳动法，每日工作 8 小时，其中午饭和午休是应当算在工作时间内的

我最近两次手机从口袋里弹出去，还好有硬膜代为碎裂

@Sketch
我这里的“失败”，指的是单元测试对业务逻辑的测试结果，而不是单元测试是否能成功达成目的。
其中第 2 、4 列对应的是单元测试成功检测出错误的业务逻辑的情况。
第 1 、4 列都是单元测试失败，但对应的业务逻辑不一定错误。

@huzhikuizainali 可以这么认为。引起业务逻辑出错的 bug 是无限的，但是业务逻辑提供的功能是有限的，所以单元测试也总是测试有限的场景。

简单一句话，单元测试本身可以说并不是和业务逻辑一个级别的程序，因为不需要用到程序的分支、循环等复杂的控制逻辑，输入用硬编码，调用和输出比较用预设的方法，整个过程都是顺序的。

> 两段代码同时出错的概率是 0.25 。但是只有一段代码出错的概率是 0.25+0.25=0.5 。所以出 bug 的总概率变成 0.25+0.5=0.75 。不出 bug 的概率从原来一段代码的 0.5 变成了 1-0.75=0.25 。

哈哈哈哈，神了！
从问题和这个回答看，显然是不知道单元测试的意义，是用来保证业务逻辑代码正确的。

但是上面这个提问不合适，因为正确的单元测试能测出问题，而错误的单元测试会掩盖问题，所以 50%的概率写出错误的单元测试时，会出现业务代码错误且单元测试错误而最终导致 bug 的情况。
做成表格就是
---------------------
业务逻辑 正确 正确 错误 错误
单元测试 错误 正确 错误 正确
测试结果 失败 成功 成功 失败
--------------------
测试结果概率还是 50%，和写代码正确的概率是一样的。显然这个简单的问题并不能解答疑问。

写单元测试的原则是，面向业务逻辑提供的功能/接口测试，而不针对/忽略实现。业务逻辑负责的是实现。所以在做这两部分工作时，不会有相同的逻辑。
至于你说两块代码出 bug ，那是另外一个问题，不是单元测试本身能避免的。单元测试本身已经足够简单了，因为就是制造输入和检查输出，极端情况下，这应该完全可以用字面量做到，如果这都能写出 bug 产生出一个永远通过的单元测试结果，那。。。我也不知道是什么鬼了

起名，不给是给变量、函数还是类、模块，这件事背后反映的，是你对这里业务的了解程度和抽象程度。这是上面回答几乎所有都没有提到的部分。
除了有个提到用 top-down 的方式去起名，这代表的是面向领域（业务）的解决方案编程（起名），是在难以做到面向领域编程时的最优选择。

跨越这一步之后，剩下的就是用中文来生成英文了。这里的问题是，翻译会给出一些近义词，英语不好的话，就会选到含义其实不合适的词。
比如简单的例子，declaration 和 definition ，work 、job 、task ，time 、duration 、date 、period ，size 、count 、amount 、length 之类的

最后才是命名风格的问题，驼峰还是下划线，无所谓，这步是最细枝末节的事情。

怀疑是哪个因素的问题，就把哪个因素变成变量，控制变量法
看你的描述，没看出来你有将 nginx 作为变量，进行单纯的加入和去掉 nginx 的并发测试，你只单独对前端和后端分别进行了并发测试，并在引入更多变量且瞎猜的路上越走越远