大意了，流水号算法出现异常

早上用户反馈，标签验证失败，提示为“标签与系统的流水号不一致”，用户那边发过来截图，系统的流水号与标签的流水号一对照，很明显，是系统生成流水号出现异常。

从截图来看，是流水号提前归零了，流水号设置6位长度，而流水号使用至99999后就归零了，又是以000001开始。而标签上的流水号为100001，因此，在扫码时，会提示流水号不一致。

我在本机测试了下，发现的确是流水号的算法出现异常，流水号不会计算最大位数，当设置长度6时，到达99999就归零，设置长为5时，到达9999就归零，这是一个BUG。

检查了一下，发现是一个低级错误，就是小于（<）跟小于或等于（<=）的区别，只需要将小于改为小于或等于即可。

WHILE (NOW_LEN <= I_LEN) AND (IS_OVER = 0) LOOP
NOW_STR := SUBSTR(H_STR,-1);
H_STR := SUBSTR(H_STR,1,LENGTH(H_STR)-1);

– 检查最后一位
LEN := INSTR(ALL_STR,NOW_STR);
IF LEN >= STR_LEN THEN
SS := SUBSTR(ALL_STR,1,1);
L_STR := SS||L_STR;
ELSE
SS := SUBSTR(ALL_STR,LEN+1,1);
IS_OVER := 1;
R_VALUE := H_STR||SS||L_STR;
END IF;

NOW_LEN := NOW_LEN+1;
END LOOP;

修改后，测试OK。按理说，这个流水号的算法上线前都会全面测试的，特别像这个数据达到最大值归零，以往项目都没有出现这个低级错误，也许是项目上线太赶，加上有之前经验，而忽略了测试吧。

幸好，这只是流水号其中一部分，流水号前面还带上日期的，因此，并不会造成流水号重码，不会造成客户标签大批量报废，这次只报废几个标签，影响不大。

这次真得大意了，也是一种教训，程序开发的逻辑是严谨，容不了一丝疏忽，一个逗号损失几百万上千万的案例常有发生。所以，关键算法一定全面测试，考虑各种可能产生异常的情况。