1.后台管理快递修改时没有调用修改状态时改变取件码的方法updateStatus()，按理应该无论是否修改状态，取件码都不变，为什么只有当状态变为已取件时取件码置空？
2.前台添加用户号码和身份证号不可重复问题及不可为空验证
不可重复问题明明设置了异常捕捉，但是控制台仍会报异常，没有按我的想法输出
3.快递表里的姓名和电话应该是收件人的名字和电话而不是用户表的账户（用户手机号），
快递表里应该有一个用户id来关联用户账号，bean里面一存多的集合，多存一的对象
4.微信端添加注册功能，登录时如果表里没有数据，就注册用户，无法注册快递员
5.页头菜单不能正确跳转
解决：都是前端的错
6.个人中心修改信息接收验证码时一个验证码可多次使用的问题
解决：每次修改完成删除存的键值对，有没有必要？原理是验证session中是否保存了一个userPhone-code的键值对，如果不删，除非清除了session，否则键值对一直在，下次再修改直接填原来的code仍然可以通过，所以要删
7.快递员登录失败，原因是登录时存的是user类，不是courier类
解决：所有快递员也是用户
心路历程：本来想把所有快递员数据加入用户表，即快递员即是快递员也是用户，登录时session中存储user类，但是登录时无法区分权限，失败。
第二种直接在登录时区分权限，保存不同的类型到session，然后每次取出都要进行判断，需要寻找加入大量if，放弃
第三种，舍弃快递员表，全部加入user表，并在user表增加权限字段，这样快递员类就不能使用，即一个user类需要对应两个dao，sql需要按需增加权限判断，剪切user类，将快递员类改名为User，通过idea改名时的关联操作，一键将所有用快递员类的地方修改为User类，然后删除快递员类，粘贴回User类，这样登录时都是User，按照权限字段判断权限，主要修改的bug在sql的使用，增加了多种dao方法应对不同场景使用
8.增加了快递状态由已签收变更为未签收时也要重新发验证码功能，本来是想应对快递员误操作提前签收的情况，可是老师说，这种快递员提前签收的情况不应该存在，我想是因为快递员只用输入取件码或者扫码才能确认签收，而这些都是用户提供的，故不存在提前签收
9.插入重复单号提示不报错
10.狗币的表单验证，有的对有的错，搞死人！！！在写验证的方法时，不光不符合正则表达式是要返回false，正确时更要返回ture，否则在调用这些方法判断时容易出错
11.不光插入会有重复的异常，更改也会
12.月榜报错，因为1号到了只有一个人在排名，list取不到后面的值！！！
13.关于模型类的设计要不要加入一对多，多对一