VBA数组赋值报“类型不匹配”的根因与规范写法

一、问题现场：一段“忽好忽坏”的赋值代码

先看一段在技术问答中非常典型的代码：

Sub aa()
    Dim ARR(), BRR()
    Sheets("Sheet1").Activate
    ARR = Range("A1:D5")                    ' 正常执行
    BRR = Sheets("Sheet1").Range("A1:D5")   ' 运行时错误 13：类型不匹配
End Sub

两行赋值看起来只差一个限定前缀，结果却截然不同：ARR 顺利拿到了数据，BRR 却在运行时抛出“类型不匹配”（错误号 13）。很多初学者的第一反应是“数组声明写错了”或“区域地址写错了”，反复检查声明语句却一无所获。要理解这个现象，必须先弄清 VBA 中“取值赋值”与“对象赋值”这两条完全不同的语义通道。

二、根因剖析：赋值语义与默认属性机制

2.1 两条赋值通道：Let 与 Set

VBA 中不带 Set 的赋值（Let 赋值）期望右侧是一个“值”；带 Set 的赋值期望右侧是一个“对象引用”。当右侧表达式本身是一个对象时，Let 赋值并不会直接失败，而是会尝试获取该对象的默认属性（Default Property），把默认属性的返回值作为实际参与赋值的“值”。

对于单元格区域对象 Range 来说，它的默认属性正是 Value。因此，“把区域赋值给数组”的本质诉求，是拿到 Value 属性返回的二维数组，而不是区域对象本身。一旦这条隐式取值链路没有发生，就等于把一个对象塞给了数组变量，类型不匹配在所难免。

2.2 回到报错代码：两条语句到底差在哪

ARR = Range(“A1:D5”) 之所以能成功，建立在前一句 Sheets(“Sheet1”).Activate 的基础上。此时的 Range(“A1:D5”) 是一个非限定引用：在活动工作表的上下文中，这个关键字被隐式解析为“活动表的 A1:D5”，并且在“取值赋值”这一上下文里触发了默认属性求值，实际效果接近于 Range(“A1:D5”).Value。区域内的数据被打包成二维数组，顺利装入 ARR。

而 BRR = Sheets(“Sheet1”).Range(“A1:D5”) 是一个完整的限定表达式，明确指向“名为 Sheet1 的工作表上的 A1:D5 区域”，返回的是区域对象引用本身。这种写法没有触发默认属性求值，相当于直接把对象赋给数组变量——对象与数组是两种毫不相干的类型，于是报出错误 13。

换个角度总结：两条语句的差别不在“区域”本身，而在于表达式被解析的方式不同，导致“默认属性是否被隐式调用”这一关键环节出现了分歧。还有一个值得注意的细节：Sheets 集合中既可能包含工作表也可能包含图表页，其成员以通用对象形式返回，后续成员访问走的是运行时绑定路径，这使得整条表达式的求值行为更加依赖运行环境，不如显式 .Value 那样确定。

三、为什么“碰巧能跑”的代码更危险

ARR 那行代码的正确性是“借来的”：它依赖活动工作表恰好是目标表这一隐式前提。这种隐式解析至少存在三类隐患：

1. 上下文依赖：一旦活动表不是预期的工作表（例如用户中途点击了其他表，或当前活动的是图表页），非限定引用要么指向错误区域，要么直接失效。
2. 位置依赖：同样的代码放在工作表代码模块中时，非限定引用的解析对象会变成该代码页所属的工作表，而不是你以为的活动表，行为随代码存放位置而改变。
3. 可读性差：阅读者无法从语句本身看出数据来源，排查问题时必须“脑补”运行时上下文。

换句话说，报错的 BRR 语句至少“错得明确”，而 ARR 语句属于“碰巧正确”。工程实践中，前者易查易改，后者才是真正深埋的坑。

四、规范写法与最佳实践

4.1 始终显式取 .Value

把单元格数据装入数组时，最可靠的做法是显式调用 Value 属性，不给隐式机制留任何发挥空间：

Dim ARR()
ARR = Sheets("Sheet1").Range("A1:D5").Value

这样无论代码放在哪个模块、哪个表处于活动状态，行为都完全一致。若希望进一步提速，可以使用 Value2：它省去了对日期与货币类型的自动转换处理，在大数据量场景下效率更高，返回结果同样是二维数组（日期会以数值形式呈现，需要时再自行转换显示格式）。

4.2 记住返回数组的几个“性格”

• 二维结构：多单元格区域的 Value 返回二维数组，第一维对应行、第二维对应列，下界从 1 开始，不受模块级 Option Base 声明影响。
• 单单元格例外：若区域只有一个单元格，Value 返回的是标量而非数组，直接赋给动态数组同样会报类型不匹配。稳妥做法是先判断区域尺寸，或统一用 Variant 变量接收后再按需处理。
• 非连续区域：多区域联合引用的 Value 只返回其中第一个区域的数据，处理不连续数据时应按区域逐个读取。

4.3 用类型工具快速定位问题

遇到“类型不匹配”时，与其反复盯声明语句，不如直接确认表达式的真实类型。在立即窗口中执行：

? TypeName(Sheets("Sheet1").Range("A1:D5"))
' 输出：Range
? TypeName(Sheets("Sheet1").Range("A1:D5").Value)
' 输出：Variant()

前者返回 Range，说明它是对象；后者返回 Variant()，说明这才是能装进数组的二维数组。一问一答之间，错误的来龙去脉一目了然。

五、延伸：批量读写的正确姿势

显式取值装入数组只是第一步，工程化地使用“区域—数组”交互还有两点建议：

1. 声明方式：用 Dim v As Variant 或动态数组接收皆可；若用普通 Variant 接收，先判断 IsArray(v) 再访问元素，可以天然规避单单元格返回标量的陷阱。
2. 写回数据：处理完成后，同样通过显式属性一次性写回目标区域，例如 Sheets(“Sheet2”).Range(“A1”).Resize(UBound(v, 1), UBound(v, 2)).Value = v，避免逐格循环赋值带来的性能开销。需要一维数组时，可借助内置的转置函数做行列转换，但要注意其调用开销，大数据量场景优先按二维数组直接处理。

六、小结

“类型不匹配”的表象之下，是对象与值两条赋值语义的碰撞：区域赋值给数组的本质是取其默认属性 Value 返回的二维数组；非限定引用在活动表上下文中被隐式解析，恰好触发了这一机制，而完整限定表达式返回的是对象本身，自然无法装入数组。理解了默认属性与隐式解析的来龙去脉，就应把“显式 .Value + 明确限定引用”固化为习惯写法——让每一次数组赋值都不依赖运气，只依赖确定性。