VLQ解码错误源于未处理continuation位：每字节低7位为数据，高位1表示继续、0表示结束；须逐字节读取并拼接，否则会误吞后续字节导致事件时间错或读多1字节。
VLQ解码为什么总读多1字节或解析错事件时间
因为Midi文件里所有变长数量（Variable-Length Quantity）字段都用7-bit VLQ编码，但很多C++新手直接按字节读、没处理最高位的continuation标志，导致把下一个事件的时间戳或类型字节误吞进来。
VLQ规则很简单：每个字节低7位是有效数据，最高位（bit 7）为1表示“还有下个字节”，为0表示“这是最后一个字节”。解码时必须逐字节读、检查高位、拼接低7位，不能假设固定长度。
- 常见错误现象：
0x80 0x01被当成两个独立字节，实际是VLQ值0x01（因为0x80的高位是1，但低7位全0；0x01高位是0，结束，最终值 =(0 ） - 正确做法：循环读字节，每次
value = (value ，直到遇到 <code>byte & 0x80 == 0 - 边界注意：VLQ最多4字节（Midi规范上限是28位），但某些损坏文件可能塞5字节，建议加计数保护，超4次就报错或截断
用std::ifstream读Midi文件时如何避免字节序和缓冲区错位
Midi文件是大端（Big-Endian）格式，而x86/x64是小端，但VLQ本身不涉及字节序——它按字节流顺序解码，无需翻转。真正容易出错的是后续的chunk header（如 "MThd"、"MTrk"）和length字段（4字节大端整数）。
读VLQ前必须先跳过header，且确保文件以二进制模式打开，否则Windows下\r\n会被误转，破坏字节位置。
立即学习“C++免费学习笔记（深入）”；
- 使用
std::ifstream file("song.mid", std::ios::binary)，漏掉std::ios::binary在Windows上必崩 - 检查header：读4字节，比对是否等于
"MThd"（注意C++字符串字面量是小端存储，但你读的是原始字节，直接用char buf[4]+memcmp(buf, "MThd", 4)） - 读chunk length（紧接header后4字节）：用
uint32_t len = (buf[0] 拆大端
解析track chunk时VLQ和event type怎么协同判断
Midi track里的每个event由三部分组成：delta-time（VLQ）、event type（可能含status byte）、data（变长）。难点在于status byte可能隐式继承（running status），而VLQ解码结果直接影响后续字节偏移。
例如，一个note on事件可能是 VLQ=0x81 0x00（delta=128），接着 0x90 0x45 0x7F（status+data），但如果前一个event已是channel 0的note on，那这里可能只有 0x45 0x7F（running status生效），此时VLQ解码完必须立刻看下一个字节是否在 0x80–0xFF 范围内——是则为新status，否则复用上次的status。
- VLQ解码函数应返回实际消耗的字节数，方便后续指针偏移（别只返回值）
- status byte范围：
0x80–0xEF是显式event，0xF0–0xFF是system exclusive或meta event，都不触发running status - 常见坑：把meta event（如
0xFF 0x51 0x03 0x07 0xA1 0x20）的0x51当成VLQ继续解——错，meta event的type后紧跟一个VLQ length字段，不是delta-time
std::vector加载全文件后做内存解析是否更稳
是，尤其对小中型Midi文件（
但要注意：Midi文件可能含嵌套chunk（如MTrk里嵌smpl子chunk），全加载后仍需按规范递归解析length字段，不能无脑扫到底。
- 加载示例：
std::vector<uint8_t> data(std::istreambuf_iterator<char>(file), {})</char></uint8_t>，简洁安全 - VLQ解码函数建议签名为：
std::pair<uint32_t size_t> decode_vlq(const std::vector<uint8_t>& data, size_t offset)</uint8_t></uint32_t>，返回值+消耗字节数 - 性能提醒：VLQ解码本身极快，瓶颈通常在event分发和回调处理，不是解码——别过早优化VLQ循环
