核心设计

核心设计页关注的是“为什么采用当前实现方式”，而不是逐个类列出接口。阅读它的最佳时机，是你已经看过架构页，准备进一步理解数据结构、配置面与优化取舍。

设计原则

• 测量先于优化：没有 benchmark 或明确证据，就不要把复杂度永久写进实现；
• 零拷贝意识：围绕 FASTQ 记录视图与批处理边界设计，尽量避免热路径上的额外复制；
• 工程一致性：构建、测试、CLI、文档与基线规范要能互相印证，而不是各说各话。

数据与 I/O 设计

项目围绕 FASTQ 记录视图、批处理缓存与读写器职责分离展开。Reader 负责把输入变成可消费的批次；Writer 负责把处理后的结果稳定输出；中间阶段则尽量只处理必要信息，而不是重新定义一套平行的数据模型。

处理管线设计

filter 与 stat 共享的是同一种工程思路：

• 先把输入组织成可批量处理的单元；
• 再在清晰的阶段边界上应用过滤、修剪或统计；
• 最后输出结果与可追溯证据。

这意味着很多“方便的小改动”其实会破坏整体一致性，例如把业务特例硬塞进 CLI 解析、把调试逻辑写进热路径，或让某个模块同时负责配置解释与数据处理。

什么时候应该停下来补规范

如果一项改动会影响公共 API、配置格式、行为边界或 benchmark 叙事，就不只是实现层问题。此时应回看 OpenSpec baseline / changes，而不是把变更藏进代码细节中。