@hwdq0012 #22 那不交叉编译，更不用使用 make 了吧

@hwdq0012 #17 ？？？交叉编译不是你说的这个吧。

@hwdq0012 #5 交叉编译跟 make 无关吧

很好奇，究竟用 make 来干什么，那么多可以替代 make 的工具，为了一碟醋包了一顿饺子

要搞清楚一个事，每一个问题，都是有其前提条件的。比如，面试官说线程比协程快，如果前提条件是并发数很低的情况（并发数比 CPU 核心数少），那么是对的。你认同的观点，同样也是有前提条件的。讨论一个问题前，要先划好场景，不然就是没完没了，毫无意义的扯皮。这家公司 pass 吧

我专门读了《 Domain-Driven Design: Tackling Complexity in the Heart of Software 》这本书，然后被那些“没读过的人”说我理解错了。更神奇的是他们就根据网上一些文章整出了自己的一套理解，还不接受反驳。一旦到代码实现层面，就各种漏洞，得不断给自己的理论打补丁。最后把简单的代码变成屎一样难以理解。整了一大堆似是而非的概念，对软件工程根本没正增益。也不知道国内为什么这么热衷于这个。

多领国

确实，上个月有新闻说到谷歌把“沉浸翻译”的请求认为是攻击，它们现在应该对短时间内频繁的请求给污染了。只有用沉浸翻译才有这样的问题

@silentsky #30 CH 的 MergeTree 索引结构，只能判断到数据在哪个段，然后将整个段加载到内存，在内存中进行遍历过滤。一个段默认大小有 8000 多行。在这个场景下，做好分表，设置好索引，B+ 树段查询速度反而会比 CH 更可观，还节省资源，并发更大。楼主这个搜索场景还需要考虑并发数，CH 的并发成本比 mysql 高了几个量级。物化视图只是 MergeTree 套了一层，底层没变

@BuGoooo #26 clickhouse 不适合做这个。上面看到你试验后，发现查询慢。这是正常的，因为 CH 做了全表扫描。CH 的索引跟 mysql 多索引不一样。如果是固定前两位和固定后四位查询，你使用 mysql ，把这两个单独提出来，作为分表键，加索引，查询速度比 ch es 还快，还节省资源

需要你再具体描述下你的搜索场景，是固定按后 3 位搜索？还是后 4 位？还是随机长度？

@lloyds 没有，我买的正版

抱歉，没看清楚，忽略我上一条回复。你试试升级到最新版本，重新安装下辅助程序

它设置有说明的，它限制了睡眠充电

怎么操作的？我直接在 DeepSeek 联网搜索，试了好几次都没复现

@FranzKafka95 #43 你认为这些评价是“形式主义”，纯粹是你自己的主观臆断，你怎么保证其他参与者都是跟你一样的想法？

从你的回复看，你完全不认为自己有错。从你的附言看，你又要去道歉，但是你的道歉只是跟你的组员们，不知道你的组员是不是转正流程的参与者？而且只在你的小组道歉真的有用吗？

让他获得公平的评价才是你该做的，你现在应该去尝试修改对他的评价，向参与者承认你自己的错误，而不是无意义的道歉！

你这种前后矛盾的言行，更加深了我对你“打压新人”的印象。

你一开始就强调他的资历非常深，我大胆猜测，你因为觉得对方年龄比你大，觉得以后不好管理，想打压下，没想到对方敢反抗。

如果你真的有反思，就不要给自己找借口，无论评论有没有意义，你做出不符合事实、不客观的评价，就是不负责任的表现

道歉没用，只是惺惺作态，自己承认错误，挽回对方的评价，才能赢得别人对你的尊重！

@FranzKafka95 #43 你的回复更加证明你在做导师这事上是完全不负责。你认为这些评价是“形式主义”，纯粹是你自己的主观臆断，你怎么保证其他参与者都是跟你一样的想法？从你的回复看，你完全不认为自己有错，但是从你的附言看，你又要去道歉，但是你道歉只是跟你组员，不知道你的组员是不是转正流程的参与者

字节做的东西还是要慎用，它们很喜欢跟风，后面如果运营不起来，就会减少资源投入，最后关闭。而且字节系的产品很多细节都打磨得不好，总是在一些莫名其妙的地方发力。

你这评价不够客观，从你描述看，完全看不出对方哪里“对问题的钻研程度有待提升”。你给对方的评价完全是不公正的。他没有任何问题，反而是你这个导师的工作做得很不尽责，居然是凭自己的喜好，来捏造事实。你应该跟对方道歉。而不是在这里扯什么思维惯式，给自己找借口。你的行事风格目前看来是：做事全凭自己喜好，掌握了一点权利就想打压别人，做错了事也没勇气承认。你是想来这里寻求安慰，好让自己心安理得吗？