作为经常帮人排查VBA旧脚本问题的开发者，我来帮你捋捋这个Run-time error 6 'Overflow'的问题——这个错误本质是数值超出了变量类型能容纳的范围，但你改了currRow的类型还没解决，说明问题大概率不在currRow本身，而是和它相关的赋值、运算环节出了问题。

常见的问题根源方向 #

• 关联变量的类型拖后腿：比如你把currRow改成了Long（能存到约21亿，完全覆盖工作表行数上限），但和它一起运算的其他变量是Integer类型（VBA里Integer最大只能到32767）。举个例子：如果有代码currRow = currRow + i，其中i是Integer，当i是32767、currRow是1时，相加结果是32768，直接超出Integer的范围，哪怕currRow是Long也会触发溢出——因为运算时会先按Integer的规则计算，溢出后再赋值给Long就已经晚了。
• 单元格数值的隐性转换问题：如果currRow是从单元格读取数值赋值的，比如currRow = Cells(1, 1).Value，那要检查单元格内容：看起来是数字但实际是文本格式？或者单元格里的数值是异常大的数（比如远超Double的范围）？不过工作表行数最多也就百万级，Double完全能容纳，这个可能性相对低，但可以排查下。
• 循环/逻辑里的异常赋值：比如脚本里的循环逻辑写错了，导致currRow被反复累加超出预期？或者初始值设置错误（比如设成了负数，后续运算时触发溢出）？不过你说工作表首行是第1行，初始值应该是正常的，但还是要确认下循环里的赋值逻辑。

实用排查步骤 #

1. 定位报错的具体代码行：先找到触发错误的那一行，是给currRow赋值的语句？还是用currRow做运算的语句？这是排查的核心起点。
2. 检查所有关联变量的类型：把和currRow一起运算的变量（比如循环计数器、用来累加的变量）都改成Long类型，避免Integer的范围限制拖后腿。
3. 输出调试信息：在报错代码行前加Debug.Print currRow，以及相关变量的数值，运行脚本后看立即窗口（按Ctrl+G调出）里的数值，直观判断是不是某个值超出了对应类型的范围。
4. 验证单元格赋值的可靠性：如果currRow来自单元格，先手动检查单元格的数值和格式，或者用Debug.Print Cells(行号, 列号).Value确认读取到的内容是不是预期的数字。

内容的提问来源于stack exchange，提问作者d3hero23