C 面防水的，擦干即可，无需维修

一直咳嗽，有可能是哮踹。有些医生经验不足，或者看病比较敷衍，所以就会漏诊误诊

@Arvis 丐版 16 寸也就多个独显，另外 CPU 多两核。你 13 寸先剪剪看呗，觉得用着还凑合的话，就没必要换了，换成 16 寸丐版，也不会提升太多的。

写代码的话，不用换 16 寸。

我做的外包很爽啊，价格我说多少就是多少，产品我想怎么做就怎么做，甲方除了偶尔反馈几个小问题和几个随手能加的小需求要求我改一下外，从来不哔哔。付钱又爽快，我超喜欢的。

表面上是这样，但这个客户我已经合作了有近 5 年了，每个项目我都站在客户的立场，为他精心设计产品，精心设计架构，同时也为客户随时提供技术咨询。内里我付出的比一般的外包多得多，同时我报价也很良心，让客户感觉超值。

然后，我把给客户开发的产品改改，增强通用性，转手就多卖了几份……

预热就是准备好等你来用。因为如果等你要用再创建线程池，就会有比较明显的等待过程。不光是线程池，连接池也是一样的。不预热的话，你会发现首次读写数据库的时间会多出几百毫秒的样子。

1 、搞一个公共类，两个 services 都调用公共类里面的静态方法。
2 、搞一个基类，两个 services 都继承这个基类。

楼主的意思大概是 A 表的某些 id 存在 B 表的某个字段，以逗号分隔。然后根据这个字段查询 A 表的记录。

直接 in 是不行的，要用函数处理一下，具体的做法可以百度。

装修师傅还在羡慕你坐在办公室吹着空调就把钱给挣了，还比他多！回家又和儿子说要好好念书考个好大学，不要像他没上大学只能赚点辛苦钱。

为啥电视机都是一个样子
为啥冰箱都是那几个样子
为啥 xxx 的样子都大同小异……

相同的内在的功能决定了外在的样式只有一个最优解，想要玩花活就得付出更高的代价。但这个世界上没多少人会愿意为你的花活付钱，所以大家都是按着最优解来做的，只能在细节上稍作改变。

先说前端，虽然是假权限，但也是需要根据用户权限来显示 /隐藏对应的操作按钮，或者更进一步显示 /隐藏相关组件。

后端既然楼主要求动态，那么鉴权就不能通过注解来实现了。你可以通过拦截器或者干脆在网关上面实现鉴权。思路无非就是通过解析 token 来获取用户信息，然后根据用户信息来鉴权。

不用管它，对于锂电池来说，只有过度放电才会损伤容量。但也不要一直充电从来不放电，我司有台笔记本一直插着电用了 2 年多，有一天电源拔掉就开不起来了，电池彻底废掉了。

突然发现手机屏幕小的好处，就是支付宝的广告在下面完全看不到。不看这个帖子我都不知道支付宝有广告，哇哈哈哈哈哈哈

别问，问就是：是。你挤占了别人的生存空间你造吗……手动狗头保命

好好商量，承诺后面交接尽量配合，好聚好散。不然人家拖你 1 个月是合理合法的。

{ "100":{ "id":100 "title":"xxx" }, "105":{ "id":105 "title":"sss" } }这种大多数情况下都不适合用来作为一个集合的数据结构。一般情况下，集合中的元素的 id 是无意义的，也没人关心它的值。这和 k/v 结构中的 key 不同，key 是约定的，是有意义的。

如果前端需要知道 100 这个 key 对应的 value，那么楼主的数据结构是合适的，如果前端只是列表显示，[{ "id":100 "title":"xxx" },{ "id":105 "title":"sss" }]这种结构才是合适的。

有键盘印，但不明显。上次换键盘的时候我提出更换屏幕，但没给换

@li353360 应该是“大博”