第一种情况：

var h0=(this.i)*30+42;

效果图如下：

第二种情况：

var h0=(this.i-1)*30+42;

效果图如下：

对比发现，直接用 i*30+42效果好些。

我认为应该是 i*30+42 , i是索引号，本来就比lis的length小1，要判断i的上一个li元素的下边框高度，正好是i*30.

个人认为，（i-1）*30+42不合理，此时如果submenu的底部距顶部的高度h如果不小于h0,即当一级菜单的上一个li的顶部距页面顶部的高度，那么此时不对悬浮层的位置进行处理，可是如果此时submenu的底部距顶部的高度h小于当前的li的底部距离页面顶部的距离,存在问题如图所示，不美观

我的测试结果如下：

1. 当submenu只包含一个dl时，(this.i-1)*30+42可以是一级菜单和二级菜单底部对齐，深究一下，是由于submenu下的dt的width为60px，那么实际的计算就应该是(this.i+1)*30+42-60,做一下变换60=30*2，故计算公式为(this.i-1)*30+42。

2. 当submenu包含至少两个dl时，使用this.i*30+42就比较合理；

   综上，这个计算公式不是一次写出来的，而是针对具体的盒子特征值具体定下的。

（个人看法，希望多多交流^_^）

我感觉i-1的时候，其实比较的是当前一级菜单li的上一个li的顶部高度和二级导航底部的高度，到最后的情况是二级导航顶部对应的是上一个li的顶部高度，如第一个图所示。不过正好二级导航栏只有一行的时候，它的高度和两个li的高度差不多，也就是差不多60px，视觉效果上面二级导航栏底部正好和当前li的底部差不多高了。如果是i+1，二级导航栏顶部对应的是当前li的底部，这时候就不太好看了。如第二个图所示。（个人看法~）