前端开发规范

编码规范

目录结构示意

开发在各个模块的src目录下进行，以system模块为例：

containers 存放前端的页面
stores 存放前端页面所需的数据
assets 存放样式表和图片资源
common 存放公共的配置文件
components 存放的是公共的组件
local 存放多语言文件

命名

（1）模块命名
统一小写，比如模块system。

（2）文件夹命名
采用小驼峰命名法，第一个单词首字母小写，后续单词首字母大写，例如：文件夹messageTemplate。

（3）文件命名
js文件采用大驼峰命名法，单词首字母大写，例如：MessageTemplate.js。

其它格式的文件采用小驼峰命名法，第一个单词首字母小写，后续单词首字母大写。

代码注释

（1）文件注释

    写在每个文件的开头/*author: xxx@xxx-china.comtime: 2017-2-17feature: 模块功能*/

（2）函数功能注释

     写在每个函数的命名的前一行// 输出变量的值function print(name) {......}

缩进

首字母缩进两格

修改webstorm开发工具的缩进方法

import文件

Import 3个或者3个以下的组件可以不需换行，3个以上需换行写在每个文件的开头

嵌套

嵌套严格遵循语义，避免非法错误的嵌套。子嵌套换行后，要比父级首字母多两个空格。

其他

1）js中函数声明推荐使用箭头函数声明，不推荐使用function声明，箭头函数的 “=>”符号前后两端与字符用空格隔开。

（2）js变量声明采用const和let，const用于声明常量，let用于声明变量，不允许使用var。

（3）项目中使用eslint进行js/html代码的自动校验，使用stylelint进行css/less代码的自动检验。

不符合规范的话，项目编译过程中会自动报错，报错时根据报错提示去修改即可。

（4）与组件状态无关的变量，不要写在组件的state下。

（5）组件内部调用定时器（setTimeout/setInterval）后，一定要在组件被卸载时清除。

可以使用组件的生命周期函数componentWillUnmount

样式规范

（1）页面边距

页面内容内外边距默认制定为：“15px”。

（2） pageHeader

pageHeader中button文内容最好控制在两位，例如：创建客户端修改为创建； 存在两个button情况下：“创建”离 “客户端管理”30px，“刷新”离“创建”15px。

（3）提示

在需要对内容补充说明时使用“Popover”-气泡卡片组件；对图标icon的解释说明用“Tooltip”-提示组件

（4）表格相关规范

“Table”组件默认大小使用size=“middle”

两张table之间间距“40px”

table如果可编辑（创建）的字段不超过3个时，使用模态框“Model”组件弹出编辑（创建）页；如果超过三个字段，则新建界面处理

后端开发规范

编码规范

命名规范

（1）代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束

    反例：_name / __name / $name / name_ / name$ / name__ 

（2）代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式 也要避免采用。

    正例：alibaba / taobao / youku / hangzhou 等国际通用的名称，可视同英文反例：DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3

（3）类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等

    正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例： macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion 

（4）方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。

    正例： localValue / getHttpMessage() / inputUserId 

（5）常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

    正例：MAX_STOCK_COUNT 反例：MAX_COUNT

（6）抽象类命名使用 Abstract 或 Base 开头；

异常类命名使用 Exception 结尾；

测试类命名以它要测试的类的名称开始，以 Test 结尾。

（7）类型与中括号紧挨相连来表示数组。

    正例：定义整形数组 int[] arrayDemo反例：在 main 参数中，使用 String args[]来定义。 

（8）domain/dto类中布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。

反例：定义为基本数据类型 Boolean isDeleted 的属性，它的方法也是 isDeleted()，RPC框架在反向解析的时候，“误以为”对应的属性名称是deleted，导致属性获取不到，进而抛出异常

（9）包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用 单数形式，但是类名如果有复数含义，类名可以使用复数形式。

（10）杜绝完全不规范的缩写，避免望文不知义

反例： AbstractClass“缩写”命名成 AbsClass；condition“缩写”命名成 condi，此类随 意缩写严重降低了代码的可阅读性。

（11）接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁 性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是 与接口方法相关，并且是整个应用的基础常量。

    正例：接口方法声明 void commit();       接口基础常量 String COMPANY = "alibaba";反例：接口方法定义 public abstract void f(); 

说明：JDK8 中接口允许有默认实现，那么这个 default 方法，是对所有实现类都有价值的默认实现。

（12）如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。 说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。

    正例：public class OrderFactory;public class ResourceObserver; 

（13）枚举成员名称需要全大写，单词间用下划线隔开。

（14）service/mapper层方法命名时，获取单个对象的方法用get做前缀，获取多个对象的方法用list做前缀。

常量定义

（1）不允许任何魔法值（即未经预先定义的常量）直接出现在代码中

    反例：String key = "Id#taobao_" + tradeId; cache.put(key, value); 

（2）在 long 或者 Long 赋值时，数值后使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。
说明：Long a = 2l; 写的是数字的 21，还是 Long 型的 2?

（3）不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。
说明：大而全的常量类，杂乱无章，使用查找功能才能定位到修改的常量，不利于理解和维护。

正例：缓存相关常量放在类 CacheConsts 下；系统配置相关常量放在类 ConfigConsts 下。

（4）如果存在名称之外的延伸属性应使用 enum 类型，下面正例中的数字就是延伸信息，表示一年中的第几个季节。

    正例：public enum SeasonEnum {     SPRING(1), SUMMER(2), AUTUMN(3), WINTER(4);     private int seq;     SeasonEnum(int seq){         this.seq = seq;      } } 

代码格式

（1）采用 4 个空格缩进，禁止使用 tab 字符。
* 说明：如果使用 tab 缩进，必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时， 请勿勾选 Use tab character；（IDEA：File>setting>Editor>Code Style>Java>Tab size）*

（2）单行字符数限制不超过 120 个，超出需要换行，换行时遵循如下原则：

1） 第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进，参考示例。
2） 运算符与下文一起换行。
3） 方法调用的点符号与下文一起换行。
4） 方法调用中的多个参数需要换行时，在逗号后进行。
5） 在括号前不要换行，见反例。

    正例： StringBuffer sb = new StringBuffer();  sb.append("zi").append("xin")...      //   3)    .append("huang")...  .append("huang")...  .append("huang"); 反例：StringBuffer sb = new StringBuffer();  sb.append("zi").append("xin")...append      // 4)("huang");   method(args1, args2, args3, ...      , argsX);     // 5)

（3）代码格式化，删除多余的import、全局变量、@Autowired注入

说明：如果使用 tab 缩进，必须设置 1 个 tab 为 4 个空格。IDEA 设置 tab 为 4 个空格时， 请勿勾选 Use tab character；（IDEA：File>setting>Editor>Code Style>Java>Tab size）

（4）全局常量或变量应全部接在一起，并放在代码的最开头，@Autowired也应紧接在一起，放在它们后面，中间避免无意义的空行影响维护效率，格式如下：

        private static final int A = 1;private static final String B = “a”;（空一行）@Autowiredprivate MapperA mapperA;@Autowiredprivate MapperB mapperB;（空一行）方法实现放在这里。

OOP规约

（1）避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。

（2）所有的覆写方法，必须加@Override 注解。

说明：getObject()与 get0bject()的问题。一个是字母的 O，一个是数字的 0，加@Override 可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编 译报错。

（3）不能使用过时的类或方法

说明：java.net.URLDecoder 中的方法 decode(String encodeStr) 这个方法已经过时，应该使用双参数 decode(String source, String encode)。接口提供方既然明确是过时接口， 那么有义务同时提供新的接口；作为调用方来说，有义务去考证过时方法的新实现是什么。

（4）Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals。

    正例："test".equals(object); 

（5）所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。

说明：对于 Integer var = ? 在-128 至 127 范围内的赋值，Integer 对象是在 IntegerCache.cache 产生，会复用已有对象，这个区间内的 Integer 值可以直接使用==进行 判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑， 推荐使用 equals 方法进行判断。

（6）关于基本数据类型与包装数据类型的使用标准如下：
** ▲所有的实体类（dto/domain）属性必须使用包装数据类型
▲所有的局部变量使用基本数据类型 **

（7）当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起

（8）类内方法定义的顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。

说明：公有方法是类的调用者和维护者最关心的方法，首屏展示最好；保护方法虽然只是子类 关心，也可能是“模板设计模式”下的核心方法；而私有方法外部一般不需要特别关心，是一个 黑盒实现；因为承载的信息价值较低，所有 Service 和 DTO 的 getter/setter 方法放在类体最后。

（9）使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛 IndexOutOfBoundsException 的风险。

               String str = "a,b,c,,";  String[] ary = str.split(",");  // 预期大于 3，结果是 3 System.out.println(ary.length); 

（10）循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展

说明：下例中，反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象， 然后进行 append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。

    反例： String str = “start”;      for (int I = 0; I < 100; i++) {          str = str + “hello”;      } 

（11）类成员与方法访问控制从严，作用域要尽可能小，考虑实际情况选择public、protected和private。

代码检查

（1）CheckStyle
CheckStyle是一个静态分析工具，可以按照预设的规范来检查源代码编写有哪些地方不合乎规范。
可以从其官网http://checkstyle.sourceforge.net/ 中下载。官网中还提供了Checkstyle的相关文档，如配置文件、代码检查项等，内容比较丰富，覆盖面也较齐全。可依据自身需要，参考官网上的相关资料。

（2）FindBugs
FindBugs 是一个静态分析工具，它检查类或者 JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况对软件进行分析。FindBugs可以显著的减少代码中潜在的问题。有助于提高最终交付代码的质量。

（3）SonarQube
SonarQube是一个用于代码质量管理的开源平台，用于管理源代码的质量，同时SonarQube还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用SonarQube。通过插件形式，可以支持包括java，C#，C/C++，PL/SQL，Cobol，JavaScrip，Groovy等等二十几种编程语言的代码质量管理与检测，针对不同的编程语言其所提供的分析方式也有所不同： 对于所有支持的编程语言，SonarQube 都提供源了代码的静态分析功能； 对于某些特定的编程语言SonarQube 提供了对编译后代码的静态分析功能。
（IDEA:File->Settings->Plugins）

其他规范

（1）List与Map的正确使用方式，都必须指明类型，除非在泛型类中无法确定类型，若不定义类型将导致unchecked警告：

    List<Map<String, Object>> list = new ArrayList<>();Map<String, Object> map = new HashMap<>();public List<String> methodName() {}

（2）判断List与Map是否为空请使用list.isEmpty() 或 !list.isEmpty()，而不要通过size()判断。

（3）判断String是否为null或空字符串请使用StringUtils工具类的isEmpty和isNotEmpty，特别注意isNotEmpty不是isNoneEmpty，经常有手误引用了这个完全相反的方法。

（4）不能在一行内批量定义数据，比如 int a, b=0; 应该换行分别定义。

（5）所有的异常都不能直接使用Exception或RuntimeException，而应该使用HAP提供的HapException，或自定义异常类再抛出。

（6）一个if中若只包含一个if，那么两个if应该合在一起，比如
if (a>0) { if (b<0){}} 应该转为 if (a>0 && b<0) {}

（7）//TODO 以及对代码块的注释应该在确定不再使用时去掉。

（8）判断boolean变量时不应使用==true或==false，而是使用if (a) 和if(!a)
判断Boolean对象时应该使用Boolean.TRUE.equals(a)，因为if(a)当a为null会报空指针。

（9）在Service上所有非@Override方法都必须为private，不应当向外暴露

（10）在做null判断时它必须作为第一个条件，否则它要么永不触发要么在它之前已经出现空指针。比如if (a!= null && axxx) 时 a!= null 必须在第一个。

（11）Map的正确遍历方法，不要使用keySet遍历：

for (Map.Entry<String, Object> entry : map.entrySet()) { 
String key = entry.getKey(); Object value = entry.getValue(); }

（12）使用indexOf判断字符串是否包含时应当替换为a.contains(“b”) 或 !a.contains(“b”)。

（13）若一个变量在声明后绝对会被赋值，那么就不需要给它赋初始值，比如：
int a; if (x>0) { a=1 } else { a=2 } 在这里a绝对会被赋值，所以不需要给a赋null等初始值。

（14）IP地址等根据环境动态变化的信息不应该出现在代码中，而应该配置在config.properties再在项目中用@Value引用，或从系统配置等地方获取。

（15）全局变量名尽量避免使用PASSWORD或PWD关键字。

（16）作为参数的变量名不应当使用无意义的字符串，比如var1或单个字母。

（17）大量的if (equals)条件判断应当使用switch代替，有更高的效率和查重作用。

（18）Service层实现类中所有涉及数据库的增删改的方法都必须带上以下注解：

    @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)

并且所在的类必须有@Transactional注解，注意千万不能用一个带有该注解的方法去调用另一个带有该注解的方法，会导致内部方法的事务不执行。

（19）对于List的遍历，在不需要用到下标时，推荐使用for each，更直观且通用性更高。for each本质上就是对Iterator的封装，能用Iterator的尽量用for each，而 for int对于ArrayList来说有很高的效率，但对于LinkedList来说效率很低，通用性不高。

异常日志

异常处理

（1）Java 类库中定义的可以通过预检查方式规避的
RuntimeException 异常不应该通过 catch 的方式来处理，比如：NullPointerException，IndexOutOfBoundsException 等等。
说明：无法通过预检查的异常除外，比如在解析字符串形式的数字时，不得不用catch NumberFormatException 来实现。

    正例：if (obj != null) {...} 反例：try { obj.method(); } catch (NullPointerException e) {…} 

（2）异常不要用来做流程控制，条件控制。
* 说明：异常设计的初衷是解决程序运行中的各种意外情况，且异常的处理效率比条件判断方式 要低很多*

（3）catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。 对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。

* 说明：对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。 *

正例：用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入密码过于简单，在程序上作出分门别类的判断，并提示给用户。

（4）捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请 将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。

（5）finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch.

* 说明：如果 JDK7 及以上，可以使用 try-with-resources 方式。 *

（6）不要在 finally 块中使用 return。

* 说明：finally 块中的 return 返回后方法结束执行，不会再执行 try 块中的 return 语句。 *

（7）捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。

* 说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况*

（8）方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。

* 说明：防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。 *

（9）防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：

1）返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。
反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。
2）数据库的查询结果可能为 null。
3）集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。
4）远程调用返回对象时，一律要求进行空指针判断，防止 NPE。
5）对于 Session 中获取的数据，建议 NPE 检查，避免空指针。
6）级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。

日志规范

（1）在实际代码的编写中，不应直接使用日志系统输出（Log4j、Logback）中的API，而应依赖日志框架SLF4J中的API，有利于维护和各个类的日志处理方式的统一。

    引包：import org.slf4j.Logger;   import org.slf4j.LoggerFactory; 声明：private static final Logger logger = LoggerFactory.getLogger(Abc.class); 

（2）尽量用英文来描述日志错误信息，如果日志中的错误信息用英文描述不清楚的话使用 中文描述即可，否则容易产生歧义。国际化团队或海外部署的服务器由于字符集问题，【强制】 使用全英文来注释和描述日志错误信息。

（3）在输出日志方面，应遵循以下原则：

1. 准确区分应该使用的日志级别。系统的日志输出级别会根据需要动态调整。非关键信息应该采用低级别输出，避免输出太多无用信息。关键信息应该高级别输出，确保不会遗漏。建议的级别如下：

   1. info级别，输出普通方法执行细节，接收的参数，返回的数据。
   2. warn级别，输出潜在的问题，但不包括致命错误。例如缺少指定参数，使用了默认参数。
   3. debug级别，输出系统、复杂模块初始化的步骤细节等，关键代码执行明细，也可以输出与业务相关的逻辑执行明细，相关数据等。 debug 级别日志是排查错误的重要依据，应尽可能输出有效的信息。
   4. error级别，只用于输出系统发生的错误。

2. 记录异常时，不应该只记录 message，还应该记录堆栈详细内容，需要调用合适的方法，传入异常。

3. 不能在代码中使用 System.out.println() 输出内容替代日志的功能。
4. 避免无意义的输出，避免遗漏必要的信息。输出日志应考虑实际情况，输出一些有助于帮助系统排查错误，或者分析系统行为的内容。
5. 禁止在日志中输出敏感信息，如密码，信用卡信息等。

（4）常规业务逻辑记录日志

常规业务逻辑通常在Service中完成，Service中的方法将由框架自动拦截，并记录执行概要。但具体的背部细节还需要开发者手动编码指定输出内容。

目前自动完成的内容有：
▲ Service方法接收到的参数
▲ Service方法的返回值
▲ Service方法执行时间

这些内容不需要开发者再手动输出，以免重复。

当在 Service 中去调用其他不能被框架拦截的方法时，如果有必要，可以手动记录类似的执行概要。具体到方法内部的细节，可以自行划分步骤、关键点等，在这样的临界位置输出必要的信息，可以采用INFO或 DEBUG 级别输出。

对于循环操作，需要特别注意，避免输出大量的日志内容。

（5）异常记录
框架有自动异常处理功能，可能以自动、统一的记录日志，保证不会重复、遗漏。当手动 try-catch捕获到异常时，有以下几种情况：
▲ 吞没该异常。视情况记录日志。
▲ 转换类型后继续抛出异常（或直接抛出）。此时可以只记录错误消息，而不必记录错误堆栈，详细错误将由后续异常捕获者处理。如果后续代码已经脱离框架控制范围，则应当记录堆栈明细。
▲ 处理异常，并继续抛出一个新异常（空堆栈）。视情况记录原始异常堆栈。
▲ 应当避免将一个异常在不同的地方重复记录。

（6）日志打印格式：LOG.info(“xxxxx {} xxx {}”, a, b）用占位符代替字符串拼接；

注释规范

注释类型

（1）Javadoc注释
Javadoc块的基本格式如下所示：

/*** The type Test.** @author xxx.xxx @xxx-china.com*/
public class Test {/*** Instantiates a new Test.** @param param    the param* @param username the username*/
public Test(String param, String username) {System.out.println(username + " is a " + param);
}
}

基本格式为类名上标明该类的作用，并且使用@author 标明作者。方法上标注该方法的作用，使用@param 标明每个参数及其意思。
可以使用javadoc工具生成，在生成的基础上适当的进行修改。

（2）失效代码不使用注释
完成后确认已失效的代码直接删除，不要使用//或/**/注释代码。

（3）代码细节注释
由//界定，专用于注释代码细节，即使有多行注释也仍然使用//，以便于和/**/区分开来。

除了私有变量，不推荐使用行末注释。
对于一些有比较复杂的逻辑，重要的以及难以理解的代码，需要使用注释。

class MyClass {private int myField; //An end-line comment
public void myMethod {
//what to doif (condition1) {
//condition commen...} else {//else condition comment...}}
}

注释内容

（1）对于调用复杂的API尽量提供代码示例，示例代码 < pre >< /pre > 包裹
（2）对于已知的Bug需要声明
（3）在本函数中抛出的exception尽量用@throws说明。
（4）代码质量不好但能正常运行，或者还没有实现的代码用//TODO:声明
（5）与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持 英文原文即可

反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋

（6）所有的枚举类型字段必须要有注释，说明每个数据项的用途。
（7）类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用 // xxx 方式。
（8）在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注 释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率

说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注 释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高 阅读效率。

（9）所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、 异常说明外，还必须指出该方法做什么事情，实现什么功能

* 说明：对子类的实现要求，或者调用注意事项，请一并说明*

（10） 在注释中用 //FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。
（11）代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑 等的修改。

数据库规范

建表规范

（1）表达是与否概念的字段，数据类型是 tinyint （1 表示是，0 表示否）。
注意：domain 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在< resultMap >设置 从 is_xxx 到 Xxx 的映射关系。数据库表示是与否的值，使用 tinyint 类型。

正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。

（2）表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只 出现数字。数据库字段名的修改代价很大，所以字段名称需要慎重考虑。

说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、 表名、字段名，都不允许出现任何大写字母，避免节外生枝。

    正例：aliyun_admin，rdc_config，level3_name反例：AliyunAdmin，rdcConfig，level_3_name 

（3）表名不使用复数名词

* 说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DTO 类名也是单数形式，符合表达习惯。*

（4）字段名禁用使用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

（5）主键索引名为 idx_< table name >pk；唯一索引名为 idx< table name >u< index number >；普通索引名则为idx< table name >n< index number >,其中< table name >是指表名去掉t<模块简写>的部分

    正例：idx_account_pk；idx_account_u1；idx_account_n1。 

（6）小数类型为 decimal，禁止使用 float 和 double。

* 说明：float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。*

（7）varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

（8）表的命名采用“t_< module >_< name(plural )>”

** 说明：< module >为规定好的模块名称的缩写（一般为两或三个字母的缩写）
注意：表名应能够明确表达存储数据的含义，不要过于笼统。**

（9）视图的命名规则：普通视图< module >< name >_v ; 多语言视图< module >< name >_vl

    正例：csh_transaction_account_v 、 gld_account_vl。

（10）如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

（11）英语是数据库对象命名的缺省语言，不允许在命名中使用拼音(模块名例外)；除了模块名之外，命名尽量使用全称，除非长度不够；如果使用简称，也应按照一定的规范进行。

（12）对于主键字段、who字段、扩展性字段和有效性字段的设计原则：
▲ 所有表数据都设计包含主键字段和who字段
▲对于业务数据表通常包括扩展性字段
▲对于基础设置性数据表通常都包括有效性字段

（13）所有表数据的设计都包含processing_status（处理状态）和reference_source（数据来源）两个字段。

processing_status 取值范围：created、updated和deleted。
reference_source 取值为模块名称的缩写，比如系统管理模块为xt。

（14）如果存储的字符串长度几乎相等，使用 char 定长字符串类型

（15）不要使用外键与级联，一切外键概念必须在应用层解决。

SQL规范

（1）不要使用 count(列名)或 count(常量)来替代 count()，count()是 SQL92 定义的 标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
* 说明：count()会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行**

（2）count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

（3）一般情况下，不要使用外键

* 说明：使用外键会使删除和更新操作十分的麻烦。*

（4）in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在 1000 个之内

（5）TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE 无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句

* 说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。*