diagnostics

作为车主，你一个点也没喷中，说明车主和非车主的差异还是很大的。

主要的问题还是车机功能太少，导航垃圾，充电速度不够快

还有你说的几个缺点是电车的，不限于实体按键，续航这些，并且特斯拉高速 130 能跑到 13 的电耗，其他家都得 16 、17 了。

特斯拉的哲学两个字，简单，好开。

简单在哪里，开启单踏板模式后，低速自动刹停，不需要脚放在刹车上；不需要踩刹车换挡，脚放在油门上控制油门，可以在低速下丝滑换挡，不需要刹停后换挡。

转向灯只有一个挡位，没有半档闪三下，一档（重按）一直闪直到回正的设计，而是用视觉判断你变道后，以及方向盘回正后自动关闭闪光灯。即使有时候没有正常关闭，轻拨即可。这个在变道场景下非常舒适。不过给的反馈没有机械打灯的足。

但是新能源的电子方向灯，真的是垃圾的要死，你有时候根本不知道这是一档还是两档，给的反馈太模糊，就像薄膜键盘的手感。

喜欢简洁的设计，那么特斯拉是一个很好的选择。

喜欢油车的机械按键，又要选择电车，那么比亚迪比较适合，基本上和油车一模一样，只是多了个大屏幕。后视镜调节都是在门上的机械按钮。


有些人可能会说，机械的安全什么的，就后视镜调节这个来说，有记忆功能，每个车主上车都是记忆上一次的座位，后视镜，机械的上车可能需要再调节一次，对于多人的场景不合适。好一点的油车（宝马）是有座椅记忆功能的

也可以通过语音唤醒让车机自动将后视镜调节高一点，但是这个语音确实存在有时候唤醒错误的情况。

飞机打多了就容易射，第二次就脱敏了，做多了就脱敏了，不熬夜也会延时点

知道有个项目叫 Spring Data REST 么？

履历不太好...毕业后没和同班同级的同学交流下吗？

打字效率不如英文啊，还要输入拼音啥的。

字节大小大于英文啊，也没效率

实现上不复杂，那你猜猜为啥没人做

哪吒 1 印象就不好，和华为一样都是卖国产情怀，但是华为在 V 站被骂，哪吒不会，看不懂。

学习不如实践快，学习能力不够，那就时间上补齐

你的头为什么尖尖的？

数据库访问一般就是两个门派：

- JPA 、Hibernate 等 ORM：这类就是解决大部分 CRUD 需求的，简单的查询，涉及到多表，复杂查询就会性能低下，上手门槛也更高
- JDBC Temple 、MyBatis 、JOOQ 这类 SQL Helper：这类就是解决复杂查询的，因为本来就是 SQL ，想咋写就咋写


因为本来就是 SQL ，因此先说说第二类的发展历程，一开始大家写 JDBC 还好，写多了发现模板代码太多了，主要是两个层面，一个是连接这边的代码，一个是 ResultSet 做数据转换的代码，所以诞生了类似于 Apache Commons DbUtils 这种工具来简化，在 Spring 环境中则是 Spring JdbcTemplate 。

接下来事情就会朝着两极发展，还是先从 SQL 说起

Commons DbUtils 、JdbcTemplate 这类框架只简化了连接和响应映射，在动态 SQL 的支持比较少，因此诞生了 MyBatis 也就是 JdbcTemplate 高级版，通过模板引擎解决动态 SQL ，并且支持预定义的一些 SQL

当然 Mybatis 被人诟病的 XML ，还有动态能力在复杂场景还是有限的，例如写一个递归形式的动态条件（再举个例子，DAO 方法只穿入一个 filter ，这个 filter 可以是普通的 KeyValue 过滤，也可以多个 KV 组成的 AnyOf 和 AllOf 多重过滤，后两者对应的就是 id in (select id from t where f1 and/or f2 and/or f3...)，这里面还可以动态拼接，我认为这种在 Java 里要用多态和类型匹配去做，MyBatis 对这个支持就不太行）

讲完了问题，就引出解决 MyBatis 这个陈旧框架的升级版 JOOQ ，这里用 TypeSafe 的 API 来编写复杂 SQL ，一来不需要频繁和 SQL 直接交互（ Mybatis 也有一些这种痛点），也能避免出错；二来动态能力增强了，我能在 Java 代码而不是 XML 了编写内容。

到这里就是 SQL 帮助类这一方向发展的极端了（如果有更好的框架，可以提出），这里没有提到其他帖子的注入 MyBatis Plus (Join ），tk mybatis 等增强，而是因为他们要做的事情和 JPA 类似。

接下来谈谈 JPA ，JPA 的诞生我认为是解决 Commons DbUtils 、JdbcTemplate 这类框架中，对于一个表应该有的大部分普通操作 CRUD 没有预定义好一些模板代码，导致用户又需要频繁去写 findById ，findAll ，findCountByXXX 等操作（如果直接用 MyBatis ，也有这个问题，因此没有一个方案是一劳永逸的），简单来说我认为 JPA 就是用面向对象的方式编写简单查询，然后无感生成对应的模板 SQL 。但是这里的问题在于，JPA 这种注解时，方法名编写查询的方式，注定写不了复杂 SQL ，这又是一个新的问题。

总结，合并，从整个历程来看，数据库访问技术里，最终是趋向两个方向：简单查询自动生成、复杂 SQL 查询代码动态化，一个是前期需求，一个是后期需求。

以 MyBatis 和 JPA 举例，这两个框架都诞生了融合二者的三方框架：

- MyBatis Plus/ Mybatis Plus Join/ tk.mybatis
- JPA Criteria API, JPA QueryDSL

JPA/Hibernate 不能替代 SQL 。您应该充分利用 JPA 和 SQL ，并将它们组合成一个成功的解决方案。
MyBatis + 自动生成类增强插件似乎可行，但 MyBatis 自身的 SQL 能力不够强力，加上生成框架大部分就是国人写的，我并不是说国人的技术能力不行，而是国内这个职场氛围和文化，诞生不出来好的框架，原因有很多：996 、35 毕业、生存压力（投放广告），相对于 QueryDSL 、JOOQ 而言，国内的插件生态，文档不完善，功能不丰富。。。