必须完全清楚文件字节布局、字节序、对齐和字段含义才可用struct解析，否则易得错误数据；常见错误包括数值异常、buffer长度不匹配、字节序混淆、填充字节未处理及字符串未截断。
Python 用 struct 解析二进制文件是可行的，但前提是**你完全清楚该文件的字节布局、字节序、对齐方式和字段含义**；否则解出来的数据大概率是错的，而且很难排查。
为什么直接用 struct.unpack() 容易出错
常见错误现象：数值明显异常（比如时间戳变成负数、字符串乱码、浮点数为 nan 或极小值），或 struct.error: unpack requires a buffer of X bytes。
- 没注意文件实际偏移位置，从头硬解导致字段错位
- 字节序搞反了：
（小端）和 <code>>（大端）混用，尤其在跨平台（如嵌入式设备传来的数据）时高频出问题 - 结构体含填充字节（padding），但格式串没显式跳过，比如 C 结构中
int8_t a; int32_t b;在内存中通常占 8 字节（a 占 1 字节 + 3 字节 padding + b 占 4 字节），而'B i'会误读成 5 字节，后续全崩 - 字符串字段没截断空字符或没按固定长度处理，
'16s'解出来是b'name\0\0...'，不手动.rstrip(b'\0').decode('utf-8')就会报错或显示异常
如何写可靠的 struct 解包逻辑
核心原则：把二进制结构当“协议”来对待，而不是一次性 unpack 整个文件。
- 先用十六进制查看器（如
xxd file.bin或 HxD）确认前几条记录的原始字节，人工对齐字段起始/结束位置 - 用
struct.calcsize()验证格式串长度是否匹配预期字节数，例如struct.calcsize('<i f> 返回 16，就说明这条记录固定占 16 字节</i> - 逐字段 unpack，而非一整条大格式串：先读 4 字节解
id，再读 4 字节解timestamp，中间用file.read(2)跳过未知 padding —— 这比靠格式符隐式对齐更可控 - 对可变长部分（如末尾字符串），先读长度字段，再按该长度读取并解包，避免硬编码长度
struct.unpack() 和 struct.unpack_from() 选哪个
绝大多数情况应该用 struct.unpack_from()，尤其当你需要多次解析同一块缓冲区（比如 mmap 映射的大文件）或做偏移解析时。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
-
struct.unpack(fmt, data)要求data长度必须严格等于struct.calcsize(fmt)，灵活性低 -
struct.unpack_from(fmt, buffer, offset=0)允许你在任意位置开始解析，配合memoryview(buf)还能零拷贝切片，性能更好 - 示例：解析第 3 个记录（每条 32 字节），直接
struct.unpack_from('<i f buf offset="2*32)</code">，不用反复 <code>seek()和read()
遇到嵌套结构或非标对齐怎么办
struct 模块本身不支持嵌套结构体或自定义对齐（比如 #pragma pack(1)），这时不能硬刚。
- 如果源结构来自 C 头文件，优先用
ctypes定义Structure子类，它能忠实复现内存布局（包括_pack_ = 1） - 若只有文档描述，且含复杂嵌套（如数组+子结构），建议改用
construct库 —— 它专为协议解析设计，支持条件字段、重复解析、上下文依赖等，struct做不到 - 不要试图用
struct解 PNG、JPEG 等标准格式：它们有头部校验、chunk 分割、压缩层，得用专用库（PIL、png）
真正难的从来不是写对那行 struct.unpack()，而是确认你手上的二进制规范文档有没有漏掉 padding 规则、字节序切换点、或某个字段其实是变长 TLV 结构 —— 这些地方一旦假定错误，后面所有解析都是徒劳。
