@waibunleung 你给 builder 定义个接口，然后 builder 的实现放到 infrastructure 里，上层调用 builder 的接口也没问题啊。我上面说把 builder 扔给 repository 是针对定义个简单搜索条件的 struct/类来说的，看做 struct/类的简单升级版。如果真想写个复杂点的 query builder，直接在 infrastructure 实现 query builder 会更好。如果还要复杂了，那考虑使用 CQRS

@waibunleung

搜索有一点儿复杂的时候，可以定义个搜索条件的 struct 或类，根据需要的搜索的内容填上信息。这个 struct/类是和具体表结构无关的。或者写个简单的 query builder，这个 qury builder 依旧是和具体数据结构无关，然后把 builder 交给 repository 进行具体的搜索

如果是非常复杂的搜索的话，应该使用 CQRS

手机能不能 root 和你手机系统有什么关系
现在 magisk 都是直接编辑 boot 镜像的

让我选，那应该是 case1 吧，case2 的想法其实是可以的，但写法有问题

case2 这写法泄露了数据结构。`user1 = userRepo.query({name = '拜拜你条尾'}, 1)` 中的 `name` 是具体 BD 的字段名 ，repository 目的之一不就是隔离具体的数据存储过程吗。这样写的话，意味着具体数据的结构溢出到了其他的领域层（比如调用 repo 的是 Service 层）

case2 改改的话 `query(id int, name string, limit int)` 自动根据 id 和 name 哪个是空值自动创建 sql，或者动态语言的话直接 定义`query(user_info)` ，根据 user_info 的的类型（ int 或 string ）来创建对应的 sql （虽说感觉后者的方法可能今后不太好维护）

罗技 G604 完美满足 LZ 需求

侧键多到让你爽到，而且侧键都很安静

@opentrade 老哥，关于怎么置顶，我 41 都回你了

看到 lz 的情况我流下泪

我做公司 mentor 的时候，公司三令五申你们自己加班到多晚都行，一定一定别让实习生工作超过 5 、6 点，到点就让实习生下班。实习生按照时薪 1000 日元计算，公司包住宿。

@opentrade https://www.v2ex.com/balance/add/alipay

lz 上次的帖子下面一堆人喷，结果 lz 还硬着头皮置顶，而且还不止一两次，有段时间感觉天天打开 V2EX 就看到 lz 得帖子，极其碍眼。这次估计评论翻车太严重了就开了新帖打算重来

怎么又是 lz 你？
这 lz 一模一样的推广自己这个 repo 的帖子，一年多前就发过
https://v2ex.com/t/606561
那时候就很多人指出 lz 这排行收录了个寂寞，lz 非但不改善，后来还长时间置顶帖子让所有人每天都被强制看到，导致我对这 lz 映像非常不好

而且这 lz 的 GitHub 账号就这一个收集类 repo，让我十分有理由怀疑 lz 这么作的目的是为了刷星

看下来有被笑到，把官方 app 给搞得像是伪造的钓鱼 app，这次的外包商给我们上了一课

@necpom 能选一加这个牌子，而且还装 Google Play 的人，我觉得知道氧 OS 和氢 OS 的概率应该不低。一般要用到 GooglePlay 的话直接就氧 OS 就行了，然后再装个酷安市场补充 google play 没有的应用。而且一加装氧 OS 都不能称之为刷机，官网下好氧 OS 的 ROM，放进 sd，进系统选设置选择 ROM 的 zip 就直接装上去了。连解锁都不用

@necpom 系统肯定能回滚，因为现在系统都是 A/B 分区，fastboot 下你直接切换到另一个旧系统的 slot 就回到更新前的系统了。但是 data 分区这部分还能不能正常用就不知道，氢 OS 转 ColorOS 时的 data 分区一加做了迁移，但是反过来能不能兼容回去就不知道了

这都能怪一加可还行

这是一加的氢 OS 因为一直以来广受诟病，所以一加放弃了氢 OS，直接在国内使用 ColorOS 代替了氢 OS 。就目前很多人国内用户的体验来说，ColorOS 是要比氢 OS 强非常多的，评价也不是特别差

LZ 收到的那个框应该就是 ColorOS 的 OTA 推送更新。LZ 看都不看就直接按掉了的话，这个问题其实并不能太怪一加，没在意 OTA 推送更新提示（可能随手点了同意更新），然后系统更新了，这赖到厂商似乎不太合理

所以一加正统还在氧 OS，前段时间 7T 都接到 android 11 的推送了，非常舒服

@luckyrayyy 格式化经常性动的不止是一行，可能整个文件都动了，大括号的位置，空行的调整之类的。整个文件都改了的话，这提交上去非常大几率会合并冲突。

lz 的这个问题的根本原因在于，代码作者提交的新代码没有经过格式化，这新代码合并到主干分支后，如果别人再格式化的话容易导致合并冲突

解决办法就是从根本上禁止提交没有经过格式化的代码，这样就能保证所有人提交的新代码都格式化过

首先强制每个人使用统一个代码格式化风格，然后在每次提 pull request 或 pr 有新提交的候用 GitHub action 强制校验代码风格，如果校验失败（比如 pr 提交的代码没有没格式化或不符合风格）的话，直接禁止 pr 合并，只有代码风格检验通过才行

@awanganddong 把你相关表结构说一下，光你这文字描述根本猜不出来你表怎么建的，搞不懂你为什么需要先查到用户的黑名单 id 数组

你的 好友关系表 的结构难道是 user_id friend_id 两个字段？然后黑名单则是通过 string 格式的数组直接保存在 用户信息表 的一个字段里？

你好友黑名单数据难道是放在数据库之外的只能先获得好友 id 列表，然后 where in ？
还是说表设计有问题？一般我觉得好友关系和黑名单信息是分开放在两个表里（或者单个表里有个字段标注是不是拉黑），想获得没有黑名单用户的信息的话，直接从好友那个表 join 不就行了，也用不到 in 的操作啊
还有一点是你真的需要一次性搜出几千个用户数据吗？做数据分析还能理解，如果拿来做网页或给 app 提供数据，你根本用不着直接把所有数据都一次性搜出来吧

@flyff1991 关键词换成英文直接搜英文文章，不去鸟被污染的中文结果了

@BeautifulSoap 啊，这里蓝绿厂系不含一加。一加虽然是蓝绿厂的，但解锁只需要一行命令