08 避坑与排查：答案不对时，往这四方向查

根因：裁包时时间戳可能秒级。如果同一条时间戳对应 成百上千条记录，它们之间的相对顺序在秒级时间戳里不可分，单纯按时间排序就会乱序。

正确做法：双关键字排序 (时间, 出现顺序/序号)。在同一时间戳内，再按记录在流量中出现的先后次序来定序，才能得到与题目"被窃取顺序"一致的拼接。

代码：rows.sort(key=lambda r:(r.time, r.seq))。示例见 07 模板。

验证：算出后反查某几条，确认与你眼睛在 Wireshark 里看到的顺序一致再提交。

为什么会漏：

• 字段名没对准：题目说 idcard，但响应 JSON 可能是 identity/sfz——先用 统计→HTTP 或导出对象确认真实字段名。
• 正则太严/太宽：\d{18} 会漏带字母的；.*? 非贪婪可能提前停。先在 2~3 条上验证再铺开。
• 多协议混抓：同一信息可能既在 HTTP 又在 DNS 外带，或跨多个连接。做法：先 统计→协议分级，把所有含该关键字的协议都扫一遍。
• 分片/重组：大文件被 TCP 分段、被 chunked 拆开，Follow/导出对象能重组；纯手抓 data 段要自己续接。

• UTF-8 vs ASCII：含中文/emoji 的字段要用 encoding='utf-8', errors='ignore' 读，否则崩溃或取到半个字符。
• 没解到头：URL 解码后仍是 Base64，要继续解。高手做法：写循环解到"不再变化"。
• Hex 大端/小端：字节序反了 → 用 raw[-i] 或 bytearray(reversed(...)) 反一下。
• 字典替换/移位：若解出来是乱但有规律（如 ROT、凯撒、自定义字母表），去在线解码或写映射表。

答案不对，按序自查：

1. 漏取了吗？ → 字段名对不对、正则全取了吗、有没有别的协议/包。
2. 错取了吗？ → 编码冗余(多空格/引号/换行)、解码没到底、字节序、UTF-8。
3. 错序了吗？ → 排序键正确吗、同秒是否乱序、要不要次级键。
4. 错编码了吗？ → 有没有多套一层编码、大小写/换行污染。

把"我用的字段、我的排序键、我的解码步骤"写下来对着题目逐个核对，通常一眼能看出问题。