工作过程中的教训

1，对于内外网需要打通的问题，需要考虑安全性的情况。 外网需要访问内网的部分接口，就只开指定的接口，不要全部开放；

2，对于发布的事情，需要谨慎对待。一次错误退回后，就得详细验证通过后再发布，决不允许反复发布。

3，定位问题的时候一切以页面问题根源作为入口，然后再打印日志； 以问题入口为起点，层层打印日志；直到找到问题原因；不要一上来认为哪里有问题就从哪里入手，因为可能还有其他人修改的地方是你不知道的。

4，定位CPU执行很慢的问题

a，数据库表的数据量是否过大，导致插入或查询很慢；

b，查看docker的fullgc等情况；

c，查看top命令查进程和查线程；

5，定位问题思路

如果2个docker容器一致，一个启动成功一个启动失败：先看日志，根据日志一步步定位；然后看配置文件是否有什么差别；再看启动命令是否有什么不同；

6，如果定位问题发现数据库数据变更，前端菜单等权限没有变更，又没有请求后端接口，那么可能是系统配置中"启用了前端缓存";

7，定位问题的思路： 日志+本地复现为准，断点调试后若复现出来可能是yml配置文件错误。比如：数据库连接配置写错了导致的卡死现象：在jdbcTemplate执行查询的时候抛错了，但是定位到指定代码时，发现sql语句按照分析的场景并不会报错。可以继续向下追查其他日志，最终定位的是jdbcTemplate在初始化传递datasource的时候，datasource初始化报错，而这个错误并没有抛出异常。

8，有时候本地改了生效，部署上去未生效，就要检查是否存在外部配置文件有覆盖的现象，同时通过日志查看外部配置文件是否在启动过程中加载进去（否则外部配置文件怎么改都未生效）

9，同一份代码，展示效果不一样的问题解决思路： 可能是数据权限的问题，可以把DEBUG日志打开进行详细排查：比如sql语句；

10，如果遇到了定时任务执行很长的排查思路：

a，使用jstack pid查询这个任务主要卡在哪里没有执行；

b，如果排查发现是表查询很慢，那么先看看这个表数据量有多少，如果超过百万，且查询又没有加上索引，那么可能就是全表扫描，所以会很慢。

c，加索引的逻辑根据查询条件来加

11，如果项目到后期因为人员问题导致项目无法收尾，可以先让此人把项目中的问题罗列出来一个个去解决，同时可以对问题用轻重缓急的程度排序，把一个个问题消灭；在消灭的过程中一个个去测试功能，保证功能的正常使用，确认异常场景能否恢复等等情况。

12，如果一个生产网站使用nginx做代理映射到了办公网，然后生产网能正常访问，但是办公网不能访问，则需要看一下nginx日志，定位日志发现是磁盘空间（df -h命令）不够，nginx日志无法写到磁盘，导致不断刷新页面的现象。

13, linux部署jar包后，jar包无法读取linux的任意目录，只能读取jar包所在的目录作为根目录。

14，很重要的一点： 在文字聊天时，切记先看懂文字内容并理解后，再答复内容。不要着急答复！要改掉这个坏毛病。

15，一件事要做的完整，需要考虑网络等异常情况导致的遗留问题；,

16，如果一个函数内，有2个方法会抛出异常，如果第一个方法的异常不应该影响第二个方法的执行的话，理论上要在第一个方法上加上try/cache，用来保证第二个方法的正常执行；

17，写代码经验 要顾名思义，既然是all了，就不要再处理过程中进行删减，可以对比过滤生成一个新的变量，因为可能其他使用者未来要更改这一部分代码时，就能够直接使用了。

18，判断一个集合中是否包含某个值：用set 不要用list,因为list要遍历查找效率低。

19，如果有些尝试不可控，那么就用自己掌握的最简单的方式去做，不要为了尝试而去尝试，除非已经很熟练。不然会冒出各种问题，简单才是王道，比如for循环用下标的方式好久用下标遍历，而不要去用什么foreach或lambda。

20，待后续再追加。。