关键在于“什么时候分、依据什么分、分错怎么办”，流程控制需将分离动作嵌入可验证、可回退、可观测的决策链，而非简单执行arraycopy或slice。
关键不在“怎么分”，而在于“什么时候分、依据什么分、分错怎么办”。流程控制的核心是把分离动作嵌入可验证、可回退、可观测的决策链中，而非简单执行一次 arraycopy 或 slice。
报文结构识别必须前置为流程起点
非标准报文没有固定格式，不能靠位置硬切。流程第一步必须是语义驱动的结构识别：
- 读取协议标识字段（如 RTSP 的 "RTSP/"、RTP 的 version+padding 字段、ASF 的 0x3026B275 magic）；
- 若标识缺失或非法，直接标记为 non-compliant，跳过后续解析，进入异常通道；
- 若标识合法，再提取长度相关字段（如 RTSP 中 CRLF 分隔后的 Content-Length，RTP 中 payload length 隐含在 UDP 包长减去 header 长度）；
- 所有提取操作必须在单次顺序扫描中完成，避免多次 rewind 或重复读取缓冲区。
分离动作必须绑定三重流程门禁
只有通过全部校验后，才允许触发分离逻辑。这三道门禁构成原子化判断流程：
- 长度门禁：header_len ≥ 0 且 ≤ buffer.remaining()，否则拒绝分离；
- 语义门禁：载荷起始处字节符合协议预期（如 RTP 的 payload type 在有效范围内，RTSP 消息体首字节不为 CR/LF）；
- 一致性门禁：头部 CRC 或校验和匹配（若协议定义），或与会话级元数据（如已知 stream ID、sequence expected）逻辑自洽。
任一关失败，流程转向异常处理分支，不生成 header/payload 视图，也不修改任何共享状态。
异常路径需独立闭环，不干扰主流程
非标准报文不是错误，而是协议演进中的常态。流程设计要为其预留专用通路：
- 主解析线程只做判定和轻量快照（如截取前 48 字节 + offset + timestamp）；
- 快照经无锁队列投递至审计模块，由单独线程异步归档、打标、触发告警；
- 恢复策略由上下文决定：RTSP 场景可跳至下一个 "OPTIONS" 或 "DESCRIBE" 行；RTP 场景可按 sequence number 丢弃越界包并等待下一个 valid marker；
- 所有恢复动作不回滚已输出的 IMFSample 或 ByteBuffer 视图，保持输出流单调推进。
分离结果必须附带可追溯的上下文标签
安全分离不只是拆出字节数组，更是构建可审计的数据契约：
- 每个 header/payload 视图都应关联 immutable context 对象，含 session ID、packet index、解析时间戳、校验结果码；
- 若使用 ByteBuffer 切片，用 .attachment() 绑定该 context，避免额外引用开销；
- 下游模块（如解码器、统计器）可通过 context 快速识别该块是否来自非标准路径，从而启用降级策略（如跳过 metadata 解析、禁用帧内依赖）；
- 日志系统自动采集 context 中的 error code 和 offset，无需额外埋点即可定位问题源头。
