一、编程规约
(一)命名规约
1. 【强制】所有编程相关命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例： _name / __name / $Object / name_ / name$ / Object$
2. 【强制】所有编程相关的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
反例： DaZhePromotion [打折] / getPingfenByName() [评分] / int 变量 = 3;
正例： ali / alibaba / taobao / cainiao / aliyun / youku / hangzhou 等国际通用的
名称，可视为英文。
3. 【强制】类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名）DO / DTO / VO / DAO等。
正例：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. 【强制】中括号是数组类型的一部分，数组定义如下：String[] args;
反例：请勿使用String args[]的方式来定义
8. 【强制】POJO类中的任何布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型boolean isSuccess；的属性，它的方法也是isSuccess()，RPC框架在反向解析的时候，“以为”对应的属性名称是success，导致属性获取不到，进而抛出异常。
9. 【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例： 应用工具类包名为com.alibaba.mpp.util、类名为MessageUtils（此规则参考spring的框架结构）
10.【强制】杜绝完全不规范的缩写，避免望文不知义。
反例：<某业务代码>AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成
condi，此类随意缩写严重降低了代码的可阅读性。
11.【推荐】如果使用到了设计模式，建议在类名中体现出具体模式。
说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计思想。
正例：public class OrderFactory;
public class LoginProxy;
public class ResourceObserver;
12.【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁性，并加上有效的javadoc注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是与接口方法相关，并且是整个应用的基础常量。
正例：接口方法签名：void f();
接口基础常量表示：String COMPANY = "alibaba";
反例：接口方法定义：public abstract void f();
13.接口和实现类的命名有两套规则：
1）【强制】对于Service和DAO类，基于SOA的理念，暴露出来的服务一定是接口，内部的实现类用Impl的后缀与接口区别。
正例：CacheServiceImpl实现CacheService接口。
2）【推荐】 如果是形容能力的接口名称，取对应的形容词做接口名（通常是–able的形式）。
正例：AbstractTranslator实现 Translatable。
14.【参考】枚举类名建议带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。
说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。
正例：枚举名字：DealStatusEnum；成员名称：SUCCESS / UNKOWN_REASON。
15.【参考】各层命名规约：
A) Service/DAO层方法命名规约
1） 获取单个对象的方法用get做前缀。
2） 获取多个对象的方法用list做前缀。
3） 获取统计值的方法用count做前缀。
4） 插入的方法用save（推荐）或insert做前缀。
5） 删除的方法用remove（推荐）或delete做前缀。
6） 修改的方法用update做前缀。
B) 领域模型命名规约
1） 数据对象：xxxDO，xxx即为数据表名。
2） 数据传输对象：xxxDTO，xxx为业务领域相关的名称。
3） 展示对象：xxxVO，xxx一般为网页名称。
4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。
(二)常量定义
1. 【强制】不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId；
cache.put(key, value);
2. 【强制】long或者Long初始赋值时，必须使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解。
(三)格式规约
1. 【强制】大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
1） 左大括号前不换行。
2） 左大括号后换行。
3） 右大括号前换行。
4） 右大括号后还有else等代码则不换行；表示终止右大括号后必须换行。
2. 【强制】 左括号和后一个字符之间不出现空格；同样，右括号和前一个字符之间也不出现空格。详见第5条下方正例提示。
3. 【强制】if/for/while/switch/do等保留字与左右括号之间都必须加空格。
4. 【强制】任何运算符左右必须加一个空格。
说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等。
5. 【强制】代码块缩进4个空格，如果使用tab缩进，请设置成1个tab为4个空格。
正例： （涉及1-5点）
public static void main(String args[]) {
// 缩进4个空格
String say = "hello";
// 运算符的左右必须有一个空格
int flag = 0;
// 关键词if与括号之间必须有一个空格，括号内f与左括号，1与右括号不需要空格
if (flag == 0) {
System.out.println(say);
}
// 左大括号前加空格且不换行；左大括号后换行
if (flag == 1) {
System.out.println("world");
// 右大括号前换行，右大括号后有else，不用换行
} else {
System.out.println("ok");
// 右大括号做为结束，必须换行
}
}
6. 【强制】单行字符数限制不超过120个，超出需要换行，换行时，遵循如下原则：
1） 换行时相对上一行缩进4个空格。
2） 运算符与下文一起换行。
3） 方法调用的点符号与下文一起换行。
4） 在多个参数超长，逗号后进行换行。
5） 在括号前不要换行，见反例。
正例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，换行缩进4个空格，并且方法前的点符号一起换行
sb.append("zi").append("xin")…
.append("huang");
反例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，不要在括号前换行
sb.append("zi").append("xin")…append
("huang");
//参数很多的方法调用也超过120个字符，逗号后才是换行处
method(args1, args2, args3, ...
, argsX);
7. 【强制】方法参数在定义和传入时，多个参数逗号后边必须加空格。
正例：下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");
8. 【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。
正例：
int a = 3;
long b = 4L;
float c = 5F;
StringBuffer sb = new StringBuffer();
说明：增加sb这个变量，如果需要对齐，则给a、b、c都要增加几个空格，在变量比较多的情况下，是一种累赘的事情。
9. 【强制】IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式，不要使用windows格式。
10.【推荐】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。
说明：没有必要插入多行空格进行隔开。
(四) OOP规约
1. 【强制】所有的覆写方法，必须加@Override注解。
反例：getObject()与get0bject()的问题。一个是字母的O，一个是数字的0，加@Override
可以准确判断是否覆盖成功。另外，如果在抽象类中对方法签名进行修改，其实现类会马上编
译报错。
2. 【强制】相同参数类型，相同业务含义，才可以使用Java的可变参数，避免使用Object。
说明：可变参数必须放置在参数列表的最后。（提倡同学们尽量不用可变参数编程）
正例：public User getUsers(String type, Integer... ids);
3. 【强制】对外暴露的接口签名，原则上不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated注解，并清晰地说明采用的新接口或者新服务是什么。
4. 【强制】不能使用过时的类或方法。
5. 【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。
正例： "test".equals(object);
反例： object.equals("test");
说明：推荐使用java.util.Objects#equals （JDK7引入的工具类）
6. 【强制】所有的相同类型的包装类对象之间值的比较，全部使用equals方法比较。
说明：对于Integervar=?在-128至127之间的赋值，Integer对象是在IntegerCache.cache产生，会复用已有对象，这个区间内的Integer值可以直接使用==进行判断，但是这个区间之外的所有数据，都会在堆上产生，并不会复用已有对象，这是一个大坑，推荐使用equals方法进行判断。
7. 【强制】关于基本数据类型与包装数据类型的使用标准如下：
1） 所有的POJO类属性必须使用包装数据类型。
2） RPC方法的返回值和参数必须使用包装数据类型。
3） 所有的局部变量推荐使用基本数据类型。
说明：POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。
正例：数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。
反例：某业务的交易报表上显示成交总额涨跌情况，即正负x%，x为基本数据类型，调用的RPC服务，调用不成功时，返回的是默认值，页面显示：0%，这是不合理的，应该显示成中划线-。所以包装数据类型的null值，能够表示额外的信息，如：远程调用失败，异常退出。
8. 【强制】定义DO/DTO/VO等POJO类时，不要设定任何属性默认值。
反例：某业务的DO的gmtCreate默认值为new Date();但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
9.【强制】序列化类新增属性时，请不要修改serialVersionUID字段，避免反序列失败；如果
完全不兼容升级，避免反序列化混乱，那么请修改serialVersionUID值。
说明：注意serialVersionUID不一致会抛出序列化运行时异常。
10.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。
11.【强制】POJO类必须写toString方法。使用工具类source> generate toString时，如果继承了另一个POJO类，注意在前面加一下super.toString。
说明：在方法执行抛出异常时，可以直接调用POJO的toString()方法打印其属性值，便于排查问题。
12.【推荐】final可提高程序响应效率，声明成final的情况：
1） 不需要重新赋值的变量，包括类属性、局部变量。
2） 对象参数前加final，表示不允许修改引用的指向。
3） 类方法确定不允许被重写。
(五)注释规约
1. 【强制】类、类属性、类方法的注释必须使用javadoc规范，使用/**内容*/格式，不得使用//xxx方式。
说明：在IDE编辑窗口中，javadoc方式会提示相关注释，生成javadoc可以正确输出相应注释；在IDE中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
2. 【强制】所有的抽象方法（包括接口中的方法）必须要用javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明：如有实现和调用注意事项，请一并说明。
3. 【强制】所有的类都必须添加创建者信息。
4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。
5. 【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词、关键字，保持英文原文即可。
反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
8. 【参考】注释掉的代码尽量要配合说明，而不是简单的注释掉。
说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。
9. 【参考】对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。
10.【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。
二、MySQL规约
(一)建表规约
1. 【强制】表达是与否概念的字段，必须使用is_xxx的方式命名，数据类型是unsignedtinyint（ 1表示是，0表示否），此规则同样适用于odps建表。
说明：任何字段如果为非负数，必须是unsigned。
2. 【强制】表名、字段名必须使用小写字母或数字；禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
正例：getter_admin，task_config，level3_name
反例：GetterAdmin，taskConfig，level_3_name
3. 【强制】表名不使用复数名词。
说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于DO类名也是单数形式，符合表达习惯。
4. 【强制】禁用保留字，如desc、range、match、delayed等，参考官方保留字。
5. 【强制】唯一索引名为uk_字段名；普通索引名则为idx_字段名。
说明：uk_ 即 unique key；idx_ 即index的简称。
6. 【强制】小数类型为decimal，禁止使用float和double。
说明：float和double在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不正确的结果。如果存储的数据范围超过decimal的范围，建议将数据拆成整数和小数分开存储。
7. 【强制】如果存储的字符串长度几乎相等，使用CHAR定长字符串类型。
8. 【强制】varchar是可变长字符串，不预先分配存储空间，长度不要超过5000，如果存储长度大于此值，定义字段类型为TEXT，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
9. 【强制】表必备三字段：id, gmt_create, gmt_modified。
说明：其中id必为主键，类型为unsigned bigint、单表时自增、步长为1；分表时改为从TDDL Sequence取值，确保分表之间的全局唯一。gmt_create, gmt_modified的类型均为date_time类型。
10.【推荐】表的命名最好是加上“业务名称_表的作用”，避免上云梯后，再与其它业务表关联时有混淆。
正例：tiger_task / tiger_reader / mpp_config
11.【推荐】库名与应用名称尽量一致。
12.【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。
13.【推荐】字段允许适当冗余，以提高性能，但是必须考虑数据同步的情况。冗余字段应遵循：
1）不是频繁修改的字段。
2）不是varchar超长字段，更不能是text字段。
正例：各业务线经常冗余存储商品名称，避免查询时需要调用IC服务获取。
14.【推荐】单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
反例：某业务三年总数据量才2万行，却分成1024张表，问：你为什么这么设计？答：分1024张表，不是标配吗？
15.【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。
正例：人的年龄用unsignedtinyint（表示范围0-255，人的寿命不会超过255岁）；海龟就必须是smallint，但如果是太阳的年龄，就必须是int；如果是所有恒星的年龄都加起来，那么就必须使用bigint。
(二)索引规约
1. 【强制】业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。
说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验和控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。
2. 【强制】超过三个表禁止join。需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引。
说明：即使双表join也要注意表索引、SQL性能。
3. 【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度。
说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引，区分度会高达90%以上，可以使用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
4. 【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
说明：索引文件具有B-Tree的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
5. 【推荐】如果有order by的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现file_sort的情况，影响查询性能。
正例：where a=? and b=? order by c; 索引：a_b_c
反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引a_b无法排序。
6. 【推荐】利用覆盖索引来进行查询操作，来避免回表操作。
说明：如果一本书需要知道第11章是什么标题，会翻开第11章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。
正例：IDB能够建立索引的种类：主键索引、唯一索引、普通索引，而覆盖索引是一种查询的一种效果，用explain的结果，extra列会出现：using index.
7. 【推荐】利用延迟关联或者子查询优化超多分页场景。
说明：MySQL并不是跳过offset行，而是取offset+N行，然后返回放弃前offset行，返回N行，那当offset特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行SQL改写。
正例：先快速定位需要获取的id段，然后再关联：
SELECT a.* FROM 表1 a, (select id from 表1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
8. 【推荐】SQL性能优化的目标：至少要达到 range 级别，要求是ref级别，如果可以是consts最好。
说明：
1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。
2）ref 指的是使用普通的索引。（normal index）
3）range 对索引进范围检索。
反例：explain表的结果，type=index，索引物理文件全扫描，速度非常慢，这个index级别比较range还低，与全表扫描是小巫见大巫。
9. 【推荐】建组合索引的时候，区分度最高的在最左边。
正例：如果wherea=?andb=? ，a列的几乎接近于唯一值，那么只需要单建idx_a索引即可。
说明：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：wherea>?
and b=? 那么即使a的区分度更高，也必须把b放在索引的最前列。
10.【参考】创建索引时避免有如下极端误解：
1）误认为一个查询就需要建一个索引。
2）误认为索引会消耗空间、严重拖慢更新和新增速度。
3）误认为唯一索引一律需要在应用层通过“先查后插”方式解决。
(三) SQL语句规约
1. 【强制】不要使用count(列名)或count(常量)来替代count(*)，count(*)就是SQL92定义的标准统计行数的语法，跟数据库无关，跟NULL和非NULL无关。
说明：count(*)会统计值为NULL的行，而count(列名)不会统计此列为NULL值的行。
2. 【强制】count(distinct col) 计算该列除NULL之外的不重复数量。注意 count(distinctcol1, col2) 如果其中一列全为NULL，那么即使另一列有不同的值，也返回为0。
3. 【强制】当某一列的值全是NULL时，count(col)的返回结果为0，但sum(col)的返回结果为NULL，因此使用sum()时需注意NPE问题。
正例：可以使用如下方式来避免sum的NPE问题：SELECTIF(ISNULL(SUM(g)),0,SUM(g))FROM table;
4. 【强制】使用ISNULL()来判断是否为NULL值。注意：NULL与任何值的直接比较都为NULL。
说明：
1） NULL<>NULL的返回结果是NULL，不是false。
2） NULL=NULL的返回结果是NULL，不是true。
3） NULL<>1的返回结果是NULL，而不是true。
5. 【强制】在代码中写分页查询逻辑时，若count为0应直接返回，避免执行后面的分页语句。
6. 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
说明：（概念解释）学生表中的student_id是主键，那么成绩表中的student_id 则为外键。
如果更新学生表中的student_id，同时触发成绩表中的student_id更新，则为级联更新。外
键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据
库更新风暴的风险；外键影响数据库的插入速度。
7. 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
8. 【强制】IDB数据订正时，删除和修改记录时，要先select，避免出现误删除，确认无误才能提交执行。
9. 【推荐】in操作能避免则避免，若实在避免不了，需要仔细评估in后边的集合元素数量，控制在1000个之内。
10.【参考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但TRUNCATE无事务且不触发trigger，有可能造成事故，故不建议在开发代码中使用此语句。
说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。
(四) ORM规约
1. 【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。
说明：1）增加查询分析器解析成本。2）增减字段容易与resultMap配置不一致。
2. 【强制】POJO类的boolean属性不能加is，而数据库字段必须加is_，要求在resultMap中进行字段与属性之间的映射。
说明：参见定义POJO类以及数据库字段定义规定，在sql.xml增加映射，是必须的。
3. 【强制】不要用resultClass当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个与之对应。
说明：配置映射关系，使字段与DO类解耦，方便维护。
4. 【强制】xml配置中参数注意使用：#{}，#param# 不要使用${} 此种方式容易出现SQL注入。
5. 【强制】iBATIS自带的queryForList(String statementName,int start,int size)不推荐使用。
说明：其实现方式是在数据库取到statementName对应的SQL语句的所有记录，再通过subList取start,size的子集合，线上因为这个原因曾经出现过OOM。
正例：在sqlmap.xml中引入 #start#, #size#
Map<String, Object> map = new HashMap<String, Object>();
map.put("start", start);
map.put("size", size);
6. 【强制】不允许直接拿HashMap与HashTable作为查询结果集的输出。
反例：某同学为避免写一个<resultMap>，直接使用HashTable来接收数据库返回结果，结果出现日常是把bigint转成Long值，而线上由于数据库版本不一样，解析成BigInteger，导致线上问题。
7. 【强制】更新数据表记录时，必须同时更新记录对应的gmt_modified字段值为当前时间。
8. 【推荐】不要写一个大而全的数据更新接口，传入为POJO类，不管是不是自己的目标更新字段，都进行update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行SQL时，尽量不要更新无改动的字段，一是易出错；二是效率低；三是binlog增加存储。
9. 【参考】@Transactional事务不要滥用。事务会影响数据库的QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
五、安全规约
1. 【强制】可被用户直接访问的功能必须进行权限控制校验。
说明：防止没有做权限控制就可随意访问、操作别人的数据，比如查看、修改别人的订单。
2. 【强制】用户敏感数据禁止直接展示，必须对展示数据脱敏。
说明：支付宝中查看个人手机号码会显示成:158****9119，隐藏中间4位，防止隐私泄露。
3. 【强制】用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定，防止SQL注入，禁止字符串拼接SQL访问数据库。
4. 【强制】用户请求传入的任何参数必须做有效性验证。
说明：忽略参数校验可能导致：
l page size过大导致内存溢出
l 恶意order by导致数据库慢查询
l 正则输入源串拒绝服务ReDOS
l 任意重定向
l SQL注入
l Shell注入
l 反序列化注入
5. 【强制】禁止向HTML页面输出未经安全过滤或未正确转义的用户数据。
6. 【强制】表单、AJAX提交必须执行CSRF安全过滤。
说明：CSRF(Cross-siterequestforgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF漏洞的应用/网站，攻击者可以事先构造好URL，只要受害者用户一访问，后台便在用户不知情情况下对数据库中用户参数进行相应修改。
7. 【强制】URL外部重定向传入的目标地址必须执行白名单过滤。
正例：
try {
if (com.alibaba.fasttext.sec.url.CheckSafeUrl
.getDefaultInstance().inWhiteList(targetUrl)){
response.sendRedirect(targetUrl);
}
} catch (IOException e) {
logger.error("Check returnURL error! targetURL=" + targetURL, e);
throw e;
8. 【强制】Web应用必须正确配置Robots文件，非SEO URL必须配置为禁止爬虫访问。
User-agent: * Disallow: /
9. 【强制】在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放限制，如数量限制、疲劳度控制、验证码校验，避免被滥刷、资损。
说明：如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并造成短信平台资源浪费。
979
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
