@LokiSharp 中国很大，不只是是上海的小学生才是小学生。浙江把编程加入高中课程就引起了广泛讨论，就大概可以管中窥豹了。当然这种教学方式是好的，希望可以慢慢推广。

盲打确实对编程有加成，但绝大多数情况下基本没影响，编程应该是脑子里想好代码了用手写出来，而不是无脑尝试（除非是解算法题这类情形）。说手速影响脑子思考速度的，以为盲打就能跟上脑速了吗？那脑子的速度也是不是太慢了点。当然还是推荐学会盲打，追求更好是每个程序员都应该去做的。但学会盲打你以为就结束了吗？还有指法要求、好的键盘、好的电脑等等等等。但这些我们觉得很好的东西没必要强求他人也要这样，也不是我比你更强我说的话就有道理，毕竟每个人都有自己学习工作的方式。

@LokiSharp 人大附小嘛，还必修课。。。

always

这个目前世面上的已经太多了。而且基本上每个公司都会有自己的一套权限模块，大一点的就再做个单点登录，本质上还都是用户、角色、菜单这些，重新撸一套除了学习没啥实际意义。

当前没必要引入时序数据库，less is more。
mysql 的话就按一分钟一条数据存储好了，如果后期数据量真的大起来，那就把近来七天的数据作为热点数据放到缓存里，过期时间设为七天，性能这方面完全不会有啥问题。

以前 mysql 性能差的一笔，各种 bug 乱飞，Oracle 则是著名的商业数据库，只要给钱一条龙服务 。现在 mysql 优化的越来越好了，从 5.7 开始性能又上了台阶，再加上免费开源所以越来越流行，但是大公司很少直接使用 mysql，基本上都是做二次开发，比如淘宝的 DRDS，美团的 DBproxy，Mycat

优点：
1.可以用来做分布式 id 更方便；
2. 具有唯一性, 可以让数据分布的更均匀；
3.字符串可以屏蔽掉 java 和 js 的一些数据类型差异，比如使用 Long 时如果数字过大会产生问题；
缺点：
1.太长了，主键会被用作聚簇索引，每次插入都要损耗不少性能，bigint 也才 8 个字节；
2.临近的数据没有相关性，不能有效利用局部性原理节省性能；
3.进行范围查询时会扫描过多的页，性能不好，这点和 2 类似。
优先推荐 Twitter 的 snowflake，但需要记得在最外层和前端交互时使用 String

@ilumer 索引覆盖是比较理想的情况，在实际中一般还要根据指针再去找聚簇索引获取整个行。我的疑惑点在于这些二级索引此时是如何处理的，如果是和其他行共有的二级索引也不可能直接删除吧？但是如果二级索引没有指向聚簇索引的记录了此时是不是会删除？删除是当前线程去操作还是异步 purge 线程去清理。

@vino2014zly 走了之后并找不到聚簇索引，不影响结果集，但是对性能会有影响。

作为开发人员，平时主要涉及的设计文档基本上是功能的详细设计和概要设计，对于它们的态度我认为是必须要有，工期紧也要先有概设，后期再补详设。但是在实际过程中不写文档的人比比皆是，但这是有问题的。正规的开发流程是先写概设然后找业务人员确认，然后写详设，叫上开发组长评审，最终把详设中的设计付诸代码，你管不了别人但你可以约束自己。

看本身学历还有心理期望。第一点是现在行行转 IT，没个本科学历都没人看，至于想进大厂，非科班 211 以下的希望就很渺茫了。第二点是你如果希望在培训班混几个月就年薪三十、四十万，我告诉你是不可能的，而且 IT 行业的起薪也不高，只是基本每年都有比较稳定的增长，但又面临一个天花板的问题，如果进不了大厂，很可能干个七八年也才 20 多 k，不过你要是觉得这样就够了就当我没说。

没有固定选型，中小项目使用 Eureka 的多，因为是默认集成，简单省事，直接堆业务代码就好了。大型项目的话各种 RPC 框架乱飞，dubbo 使用确实不少(淘宝内部是 hsf 居多，dubbo 本身使用较少)，但是其它如 grpc、thrift(可以跨语言)等也很多，还有自定义 RPC 协议的。

1.数据库在初始化的时候没有进行连接的建立;
2.数据库连接报错了，只不过日志中没有输出；
3.日志输出了, 只不过被 console 屏蔽掉了;
4.console 没有屏蔽, 只是你没找到。

1.最简单的就是改 sql, 可以区分或者不区分大小写，比如 mybatis 中的 if 标签;
2.把生产环境设置为不区分大小写，但这样对于需要区分大小写的场景不太友好，需要对返回的结果集进行筛选;
3.对检索字段的字符进行全排列, 每个都去查一次, 这种方式唯一的好处就是不动数据库, 但是贻害无穷。

这个没有严格限定，在图中的 Null、Robot、NullRobot 都是开发自定义的接口或类，他们都是由 AppClassLoader 加载(Tomcat 比较特殊，有自定义的 WebClassLoader)，所以实际上它们必然由同一个 ClassLoader 加载(如果你没有自定义 ClassLoader 并使用其加载)

@wysnylc 正是为了强制注入，不然实际运行时注入失败还可以正常启动但业务代码还会报 npe, 当然在前期开发中使用 field 也无可厚非，相互之间可以独立，因为注入本身此时也变动的十分频繁，但当项目进入正常的迭代周期了，就不应该使用此种方式。构造器注入使得注入的服务不可变, 在实际的代码运行可以规避很多问题, 此外 5 个以上的依赖使得代码过于臃肿, 这时候应该考虑下设计模式了，为什么你会有这么多的服务要注入, 是不是拆分的不够细, 一个拥有 5 个注入以上的类大概率本身就很臃肿。当然在传统行业中业务本身确实及其复杂，但实际中仍不应该随意复用，举个极端的例子，我有一个列表查询, 我已经有了一个单个的查询，此时要不要复用是有待商榷的而不是无脑复用, 我见过有人为了复用竟然单个的查询也用列表查询查出来然后再取出来，完全罔顾了列表查询中不必要的操作和数据库更大的耗时。