看看雷鸟这个牌子的。

如果想学新领域的知识，又不想花自己休息时间的话，可以先找些相关的播客或者语音课程，然后在上班路上听，把路上时间利用起来，与其一路疲惫什么都做不了，不如听一点东西，积少成多，时间利用起来了，新领域的知识也接触到了。

感觉缺乏行动力，有时候是因为自己定的目标太模糊太不现实了，定些小的具体的目标先动起来吧。

@MurkeyMua 我没说苹果笔记本平台性能不行啊，选择高性能同时会带来高温，这不就是消费者自己权衡选择产品的结果吗？对比笔记本平台，桌面平台在相同性能的基础上，温度表现会更好，这是事实啊。

你是不是把我的话误解成：苹果笔记本性能干不了这么重的任务，才导致高温了？我可没这个意思。

什么任务让笔记本这么高温度，我觉得这种任务场景不太适合用笔记本了吧，选择桌面平台会更合适。

我觉得困扰你的不是时间提醒，而是你要去刻意“写”日报。

假如习惯把每天做的事情整理成待办事项，那么到了“写日报”的时间，你都不用刻意去写，稍微改一改，增加点润色，补充点细节就行了。

你可以选择不分层，但你最好要知道什么时候需要分层，分层是为了解决什么问题，要有重构思路。

楼主觉得离谱的原因是什么？
公交车司机因为失职，导致车上乘客死亡，司机要对此负责，这不是很正常的事情吗？

不只是公交车司机，交规里规定的，只要是司机都要对车上乘客的安全负责的。车辆出了事故司机是要对乘客负责的。
建议楼主去了解下基本的交规，也可以找公交车司机或者出租车司机聊聊，了解下基本的道路安全常识。

小手推荐 g304 ，非常好用，很轻巧。

我也遇到过，之前把老 iphone 数据迁移到新 iphone 上，google authenticator 的数据会丢失。
一般网站会提供重置方案的，比如发特定邮件，不复杂的。

mini 和其他 ipad 的产品定位是完全不同的，虽然产品命名都是以 ipad 开头的。

mini 的定位是移动便携，随身携带，随处使用，可以理解为随身带了一本记事本。

其他 ipad 的定位是电脑，大和重的特点决定了它要有特定的使用环境，比如有个桌子或者有个支架，没人会长时间用手拿着 ipad 使用的，那手有多累。

先明确一个概念：Authentication 和 Authorization 是两个不同的职责，互相没有强依赖关系，只是在常见的业务场景上会组合在一起使用，这两者是各自独立存在的。

打个比方：用户和订单在常见的业务上会组合在一起使用，但他们没有强依赖关系，是各自独立存在的。那把用户和订单放到一个项目里好吗？显然是不合适的。

“这两个总是同时存在的，做在一起不好吗？”
——这个问题的本质是如何确定服务的职责边界？如果处理不好，就会往单体架构发展，优缺点就很明显了。

我阳康后咳嗽一个月了，中间一直在用止咳化痰的药，但是治标不治本。
后来去看呼吸内科，做了抽血、肺功能检查和 CT ，医生说有支气管炎和肺部结节，配了消炎药和治疗结节的药。
在呼吸内科看的时候，有很多人都是咳嗽了很久，一查发现是支气管炎和肺部结节的。
我建议是咳嗽很久就直接去医院做好完整的检查，不要只依赖于止咳化痰的药。

“咱就是说，一个小的发放优惠券活动，也没人跟我说要做个「活动中台」啊。
这么一个小的验证性需求，一定要搞个巨复杂的系统出来吗。我们都做过太多无用的业务，最烦的就是过度设计。你设计的再完善最后也不可能满足产品所有需求，难不成啥需求都得做一套低代码平台出来么。

好的架构应当是随着业务的发展生长出来的不是么。”

问题不在于你的设计方案是不是合理，而是你和领导对这个产品需求的技术方案设计方向的认知出现了差异。
不知道你和这个领导是不是第一次共事。
如果是的话，那就是缺少事前沟通达成共识的流程。
如果不是的话，那就是双方没有形成“默契”。

假如事前就和领导沟通过，把上面你的认知表达出来，消除不确定性，交换意见达成共识，那就没有现在事后“批斗”的事情了。

你的服务组成总共有三个组件：Java 应用，Redis ，MySQL 。
思路：隔离组件测试，找瓶颈点。
经验：大概率瓶颈点是 MySQL ，在上面的三个组件里，关系型数据库的性能是相对很低的。

想想如果处罚力度不是那么大，事情会发展成什么样子，一个以用户内容为价值的社区慢慢会被无价值内容的帖子淹没掉，这个社区也就失去价值了。

想想足球比赛上，裁判是怎么用红牌来控制比赛双方动作尺度的，如果对恶劣的行为没有及时做出严厉的处罚，那么比赛将会失控，这种情况足球场上不少见的。

抽象一下，如果一个系统里出现了个别捣乱的苗子，而这种苗子是有传染性的，最终这个系统会被腐坏掉。为了防止这种发展趋势，必须有严厉的处罚手段进行干预。

“扼杀在摇篮里”说的这种现象和对策。

27 号投的邮箱，10 年经验，请问一般多久会联系？

按你的例子，车的状态是可能同时存在的。

状态对象 {
状态码,
颜色,
优先级
}

假如系统当前命中的状态是：车速太快状态, 汽油不够状态。
那么就将这些命中的状态放到一个集合中：[车速太快状态对象, 汽油不够状态对象]。
针对这个集合做排序和筛选策略，最终得到你认为优先级最高的状态对象，使用这个状态对象的颜色进行显示。

请问下哪些维生素对痤疮比较有效？

[因为我们是用线程池去批量拉取 MQ 中的数据进行处理的，然后他说处理速度太慢，他说在线程池后面还得再加个线程池？整了半天，弄了个线程池套娃方案，把我给整懵逼了。]

我猜测，他的意思可能是消息分派线程和消息处理线程分离，提高消息处理的并行度。
每种技术方案都是要看实际的业务场景的，也许在你们的场景下已经能够满足了，就没必要再进一步做优化了。
他可能是从理论角度出发觉得还有优化空间，但是脱离了你们的实际业务场景，所以两边的认知是不同的。

要了解为什么采用现在的方案，以及未来的可能优化方向是很有必要的。
现在可以不做优化，但需要去思考未来可能的优化方向，心里有底。

[我说我们这个设计都走了差不多五六轮评审，也有高级技术专家把关，所以应该没有什么很明显的缺陷。]

这个理由其实没有太多说服力的，如果说是在当前的业务量下，这种方案的处理速度可以满足需求，并且未来如果业务量增长的情况下，有比较明确的优化方向，这种更能说服人，毕竟优化应该是一步一步来的，随着业务量去适应的。


[后续我回答他的问题，他要么说我没答到点子上，要么就说我只答对了一半，导致我开始自我怀疑，然后觉得他深不可测...]

这个不用太在意，有些面试官会愿意花时间和面试者交流技术，有些不愿意花时间，说一半藏一半。你可以多问一句，他如果不愿意给你解答和线索，那也无所谓，自己回去查就是了，面试本来也是学习的一种机会。