工具技巧

概念	用法详解	示例附件	记录时间
java 1.5版本引入枚举的特性 目的是替代常量类 使用常量类,创建私有的构造器 Java 枚举(enum) 详解7种常见的用法	用法一：常量 用法二：switch 1.6特性,switch支持字符串 用法三：向枚举中添加新方法 用法四：覆盖枚举的方法 用法五：实现接口 用法六：使用接口组织枚举 用法七：关于枚举集合的使用	<<枚举(enum) 详解7种常见的用法.txt>>
mybatis	转义符： 符号 小于 小于等于 大于 大于等于 和 单引号 双引号 原符号 < <= > >= & ' " 替换符号 &lt; &lt;= &gt; &gt;= &amp; &apos; &quot;
spring版本说明	GA:General Availability,正式发布的版本，官方推荐使用此版本。在国外都是用GA来说明release版本的。 PRE: 预览版,内部测试版. 主要是给开发人员和测试人员测试和找BUG用的，不建议使用； SNAPSHOT: 快照版，可以稳定使用，且仍在继续改进版本。 版本说明:
POJO POJOjavabean对象，根据作用的不同进行区分，VO/BO/DTO/PO	PO DTO VO BO 都叫POJO，就是个简单的java对象； DAO 是进行数据库增删改查的类。 BO 业务对象，封装对象、复杂对象 ，里面可能包含多个类； DTO 传输对象，前端调用时传输 ； VO 表现对象，前端界面展示。 po 持久化对象，它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系
编码日志	3.2 Log中的要点 3.2.1 Log上下文 在Log中必须尽量带入上下文的信息，对比以下俩个Log信息，后者比前者更有作用 "开始导入配置文件" "开始导入配置文件[/etc/myService/config.properties]" 3.2.2 考虑Log的读者 对于用户级别的Log，它的读者可能是使用了你的框架的其他开发者，可能是运维人员，可能是普通用户。你需要尽量以他们可以理解的语言来组织Log信息，如果你的Log能对他们的使用提供有用的帮助就更好了。 下面的两条Log中，前者对于非代码维护人员的帮助不大，后者更容易理解。 "开始执行getUserInfo 方法，用户名[jimmy]" "开始获取用户信息，用户名[jimmy]" 下面的这个Log对于框架的使用者提供了极大的帮助 "无法解析参数[12 03, 2013]，birthDay参数需要符合格式[yyyy-MM-dd]" 3.2.3 Log中的变量用[]与普通文本区分开来 把变量和普通文本隔离有这么几个作用 在你阅读Log的时候容易捕捉到有用的信息 在使用工具分析Log的时候可以更方便抓取 在一些情况下不容易混淆 对比以下下面的两条Log，前者发生了混淆： "获取用户lj12月份发邮件记录数" "获取用户[lj1][2]月份发邮件记录数" 3.2.4 Error或者Warn级别中碰到Exception的情况尽量log 完整的异常信息 Error和Warn级别是比较严重的情况，意味着系统出错或者危险，我们需要更多的信息来帮助分析原因，这个时候越多的信息越有帮助。这个时候最好的做法是Log以下全部内容： 你是在做什么事情的时候出错了 你是在用什么数据做这个事情的时候出错了 出错的信息是什么 对比下面三个Log语句，第一个提供了详尽的信息，第二个只提供了部分信息，Exception的Message不一定包含有用的信息，第三个只告诉你出错了，其他的你一无所知。 log.error("获取用户[{}]的用户信息时出错",userName,ex); log.error("获取用户[{}]的用户信息时报错，错误信息：[{}]",userName,ex.getMessage()); log.error("获取用户信息时出错"); 3.2.5 对于Exception，要每次都Log StackTrace吗？ 在一些Exception处理机制中，我们会每层或者每个Service对应一个RuntimeException类，并把他们抛出去，留给最外层的异常处理层处理。典型代码如下: try{ }catch(Exception ex){   String errorMessage=String.format("Error while reading information of user [%s]",userName);   logger.error(errorMessage,ex);   throw new UserServiceException(errorMessage,ex); } 这个时候问题来了，在最底层出错的地方Log了异常的StackTrace，在你把这个异常外上层抛的过程中，在最外层的异常处理层的时候，还会再Log一次异常的StackTrace，这样子你的Log中会有大篇的重复信息。 我碰到这种情况一般是这么处理的：Log之！原因有以下这几个方面： 这个信息很重要，我不确认再往上的异常处理层中是否会正常的把它的StackTrace打印出来。 如果这个异常信息在往上传递的过程中被多次包装，到了最外层打印StackTrace的时候最底层的真正有用的出错原因有可能不会被打印出来。 如果有人改变了LogbackException打印的配置，使得不能完全打印的时候，这个信息可能就丢了。 就算重复了又怎么样？都Error了都Warning了还省那么一点空间吗？	1.log日志 https://blog.csdn.net/debugdegug/article/details/47128141?utm_medium=distribute.pc_relevant.none-task-blog-baidulandingword-2&spm=1001.2101.3001.4242	20200818