VBA调用Windows API时使用非文档标注数据类型的安全性判定咨询

VBA的Declare语句做API参数传递时，本质只做内存长度匹配，不校验类型语义，这是你能灵活替换参数类型但偶尔出现隐式问题的核心底层逻辑。只要符合以下3个硬标准，就能保证类型使用的安全性：

• 参数内存长度必须严格匹配API预期
  比如64位下API要求的8字节参数，你选择的类型必须正好占用8字节内存。你测试可用的LongLong、Currency、拆分式UINT64结构体本质都满足8字节长度要求，所以不会直接触发崩溃，但语义不匹配时会出现非预期结果。
• 排除带VBA隐式转换的特殊类型
  哪怕长度匹配，也不要使用Currency、Date这类带内置语义转换的VBA特有类型。你用Currency接收QueryPerformanceFrequency结果时自动除以10000的问题，本质是VBA对Currency类型做了固定1e4比例的定点缩放处理，和API本身无关，这种隐式转换很难排查，直接规避即可。
• 结构体参数必须严格对齐内存布局
  你测试时定义的双LongLong字段的UINT64LL结构体总长度为16字节，远大于API要求的8字节，API只会向传入的内存地址写入前8字节数据，所以自然只有低段字段有值、高段为0，这属于结构体定义错误，不是通用规则。正确的拆分式UINT64结构体应该定义为两个4字节Long字段，总长度8字节，高低位各占4字节：

  Public Type UINT64
      LowPart As Long
      HighPart As Long
  End Type
  

64位整数类参数的通用选型建议 #

针对所有输出为有符号/无符号64位整数、或8字节长度简单结构体（比如FILETIME）的场景，只要你的业务不会用到超过9223372036854775807的无符号64位值（绝大多数常规场景都不会触及该边界），完全可以统一用LongLong类型传递参数，不会有转换问题。
API只会读写你传入地址指向的内存空间，LongLong在64位VBA中正好占8字节，没有任何内置隐式转换，只要你自己清楚数值的实际语义（比如无符号值不要直接做负数判定），使用是100%安全的，可以大幅降低开发成本。

其他常规场景的固定选型参考：

• 所有指针、句柄类型：统一用LongPtr，可同时兼容32/64位环境
• 4字节整数参数：用Long
• 2字节整数参数：用Integer
• 1字节参数：用Byte
• 字符串参数：根据API编码要求，ANSI版本直接传String，Unicode版本传StrPtr(字符串变量)

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