java开发之我挖过的坑

        自以为开发经验多了犯低级错误的概率会减少，被同样的问题一次次打脸后我深刻认识到我太高估自己了，以为自己的大脑足够用，能自带免疫功能；其实一直都知道减少犯同样错误的唯一方法就是不断的积累和总结，偷懒真的会摔跟头，自己挖的坑还是要自己填。

       于是我的错误总结由此开始。。。。

       从哪个bug写起呢？如果要把我开发至今的bug都列出来，估计要写一本书吧，这就是一段不堪回首的血泪史啊啊啊啊啊。

       经过一番挑选之后我决定记录下一些比较容易忽略和经常出现的bug。

一，反射型xss漏洞

       正如下图所示，传入参数是字符串类型这种情况；如果有对参数进行输出，记得要把参数转义后再输出，或者输出不带参数

如何转义呢，以下面为例

1.  jsp页面，将输入的字符串参数转码：

2. addProduct.jsp接口，将转码的字符串解码后输出：

二，传异常值报错

        惯性地用正常值进行测试往往忽略了异常值的结果，以下两种情况都是没有对传入参数的数值范围进行充分测试。

1.

2.

  针对第二种pageNo传入超大页码的情况，可以先判断是否超过当前最大页码，超过时直接返回空数据不再进行查询。

Pager<Account> totalAccountPager = accountService.getSuccessApplyAccount(1, 1, trialID, accountId);
	int total = 0;
	if(totalAccountPager != null){
		total = totalAccountPager.getTotal();//总数据量
	}
	int count = total > pageSize ? (total/pageSize + total%pageSize) : 1;//总页数
	Pager<Account> accountPager = null;
	if(total > 0 && pageNo <= count){  //在页数范围内才进行查询
		accountPager = accountService.getSuccessApplyAccount(pageNo, pageSize, trialID, accountId);
	}	 

三，性能超标

性能超标不外乎三种原因：sql效率低，需求规则复杂和代码逻辑问题。首先是解决sql和代码逻辑问题，如果还是超标才考虑需求规则是否可以更改。如果以上三个优化后还是超标就看超标率是否在接受范围内了。

四，代码逻辑不严谨（这个不知道怎么定义，先这么叫吧）

1.

.

当集合idList为空时调用addAll方法会报空指针，因此我先判断idList非空时再调用addAll方法；不会报错了，但问题来了，我忽略了其为空的情况；因为下面有个排除的规则，如果idList为空，但ids集合不为空，ids不会被加入idList集合中，排除步骤里不会将ids排除掉，所以考虑为空的情况做了以下修改：

2

这里只判断了产品是否存在，但忽略了是否是审核通过的产品，所以判断对象需要全面

五,浏览器的兼容性

对浏览器的兼容性主要是页面的样式兼容，一般的浏览器包括chrome 火狐 360 搜狗 IE；需要在不同浏览器上测试页面是否正常显示

六，输入的字段长度与实际数据库保存的长度要匹配

数据库中无论是中文还是英文都占一个字符的长度，代码若根据编码判断两个英文相当于一个中文的长度，此时如果允许输入的最大长度和数据库的长度一样，当输入最大长度时页面判断会通过但数据库会由于超过字段长度报错

解决方案：保持前端页面和数据库判断的一致性，页面不根据编码来判断，将中文和英文的长度都看作一样；或者修改数据库字段的长度，但这个不太可取，因为起码要将长度加大一倍才能满足要求。