先把需求想清楚说明白…… 多表联查，表呢？要查什么？关联条件是什么？

emmm, 感谢分享, 已注册😂

不到 10%。没定投。

加糖加奶加茶。

从楼主的描述看，这个问题得老板自己背了。线上偶发 bug 是很难找的。经验丰富的开发者能避免很多问题，但谁也不敢保证会不会遇到自己没遇到过的。这是必然损失。老板如果不管技术的话，责任可以让手下负责技术的主管来背。

茶位费重点是位，不是茶…… 有没有茶都不影响的…… 楼上有些纠结有茶没茶的不要被名字误会了……

酷

待我刷刷题，年后必来投！

老眼昏花，看成了练兵器……

不一定是技术问题，也不一定是你的问题。随缘吧。

你这是新需求。

@Braisdom #48 这不是规律，也不是原理…… 你是不是对规律和原理两个词有误解？我为了实现某个需求，制造了一个工具，你跟我说这个需求是工具的规律？？代步是汽车的规律吗？

@hello158 #50 这个问题是需要琢磨，但是背后并没有什么“规律”和“原理”需要去发现，而是需要总结出一套适合自己实际情况的并且自己喜欢的异常处理机制。这套机制因人而异。

@Braisdom #44 我再重复一遍…… 当你引入一个概念的时候，你得指出它的特有之处，而不是共性。如果它没有独特之处，那它有什么存在必要呢？

Java 为什么要搞出个 interface, 这要真是个题，那么最大的得分点只会在多重继承上。而这个点，也是几乎所有教材都会提到的内容，并不需要自己瞎琢磨。

我一路看下来，你的思路似乎都是顺毛撸，看到一个东西，啊怎么好怎么好，符合什么什么；但是计算机程序语言的问题大多时候更多的是个取舍问题。要达到一个目的，可以 A 可以 B 可以 C，为什么用 A 不用 B 不用 C，ABC 各有什么优缺点，选择用 A 而不用 B 或者 C 是个好的决策还是不好的决策，这个好或者不好的判断是基于什么而言。这些问题才更能抓住本质。而这些问题读一下各个特性引入时设计者自己的说明、语言的演变历史之类的可以解决很大一部分，剩下的才需要自己思考，想想他们说的对不对，有没有别的他们没考虑到的地方。

@xzour #17 他是怀疑你每次都只读一条，这样大量时间耗费在数据库交互上。如果你一次全部读出来，那自然是无所谓，这个位置也不会是 db.search