我原样复制你的，能找到。语法也没问题。
你确定你用的是你贴的命令，而不是 --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 的并发测试，你只单独对前端和后端分别进行了并发测试，并在引入更多变量且瞎猜的路上越走越远

@onceMore 主从的延迟还是存在的，看数据量和业务吧，还是见到过几次因为业务逻辑不合理而出现数据一致性问题的情况。

ES 集群维护起来比数据库方便是吧。。。
流量不大数据量不大，提高主库的硬件性能不行吗，搞这么复杂的方案

我昨天睡觉之前特别困，但是多熬了一会儿，不太困了，才上的床。过了一会儿没睡着，突然心慌肌肉乏力颤栗，能量缺失的感觉，赶紧胡吃海塞了一堆，加上葡萄糖片。之前也偶尔发生。
怀疑是很困的时候还不睡，大脑消耗了过多能量，加上晚上就吃了 7 分饱。
但是不知道这是不是一种病症。和低血糖症状不一样，那个是眼发黑头发晕。

没有用 PingCode 的吗