justplaymore

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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