struct.unpack() 解析二进制数据时必须显式指定字节序（如'>i'或'!i'），避免因本机序与网络序混淆导致数值错误；固定长度格式不支持变长字段，需手动分段解析并校验长度与对齐。
struct.unpack() 解析固定长度二进制数据时字节序写错会直接报错
Python 的 struct.unpack() 对字节序极其敏感，写成 'i'（默认本机序）却传入网络字节序（大端）的 b'\x00\x00\x00\x01'，结果会是 16777216 而非预期的 1。必须显式指定：'<i>（小端）、<code>'>i'（大端）或 '!i'（网络序，等价于 '>i'）。
常见错误现象：struct.error: unpack requires a buffer of 4 bytes 表面是长度不够，实际常因字节序不匹配导致解析位置偏移、后续字段全乱。
- 用
struct.calcsize(fmt)提前校验格式串与字节长度是否一致 - 从协议文档确认字节序——嵌入式设备多用大端，x86 程序多用小端
- 避免混用：不要在同一个
unpack()调用中混合' 和 <code>'>'前缀
处理变长字段（如字符串、数组）不能只靠 struct.unpack()
struct 模块只支持**编译时已知长度**的格式，比如 '5s' 固定读 5 字节，但真实协议中字符串常以 \0 结尾或前置长度字节。强行用 '100s' 会把后面所有字段一起吞掉。
典型使用场景：解析一个带长度前缀的字符串字段，例如 b'\x03\x00hello\x00more_data'（前 2 字节是 uint16 长度，后接字符串）。
立即学习“Python免费学习笔记（深入）”；
- 先用
struct.unpack('>H', data[0:2])提取长度n - 再切片
data[2:2+n]获取字符串原始字节 - 最后用
.decode('utf-8', errors='ignore')转字符串（注意空字节和编码异常） - 剩余数据从
2+n开始继续解析
嵌套结构体需手动分段 unpack，struct 不支持自动递归
协议里常见“头 + 多个相同子项”的结构，例如：16 字节头部 + 后跟 3 个 8 字节记录。有人误写 struct.unpack('>16s3Q', data)，但 '3Q' 是连续 3 个 uint64，不是“重复解析 3 次某子结构”。
性能影响明显：一次大 unpack 比多次小 unpack 快，但可读性和维护性差很多；而手动循环调用 unpack() 更清晰，且便于插入校验逻辑。
- 头部单独 unpack：
header = struct.unpack('>4I', data[0:16]) - 计算子项起始位置：
offset = 16 - 循环解析每个子项：
for i in range(3): record = struct.unpack('>2d', data[offset:offset+16]); offset += 16 - 务必检查
len(data)是否 ≥ 所需总长度，否则抛struct.error
字节对齐问题让 unpack 结果错位，尤其涉及 C 结构体移植
C 编译器默认按字段最大对齐数（如 8 字节）填充，而 struct 默认也启用对齐（'@' 和 '='），但行为依赖系统。比如 C 中 struct {char a; double b;} 在 x86_64 上占 16 字节（a 占 1，补 7，b 占 8），若用 'c d' 解析，会漏掉填充字节，导致 b 读错。
兼容性关键点：协议文档若明确说“packed”，必须用 ' 或 <code>'>' 显式禁用对齐；否则可能和 C 端收发不一致。
- 用
'<c8s> 替代 <code>'<c d> 来跳过隐式填充</c> - 对比
struct.calcsize('c d')和struct.calcsize('<c d> —— 前者可能是 16，后者是 9</c> - 抓包验证：用 Wireshark 查看真实二进制流，对照 Python 解析结果逐字节比对
