为什么选择 FastQTools
FastQTools 面向的是 FASTQ 质控里最常见、最需要稳定吞吐与可审计结果的那一段工作，而不是把整条生信流程重新做成一个平台。
它试图解决什么问题
很多团队并不缺“能跑 FASTQ 的命令”，真正缺的是一套能同时解释采用理由、性能前提、维护边界和集成方式的工程化工具包。
真正影响采用决策的，往往不是命令有没有列全，而是下面这些工程问题是否被正面回答：
- 吞吐是否可解释：当 FASTQ 文件量持续增大时，瓶颈通常来自 I/O、字符串复制、线程利用率和背压，而不只是算法本身；
- 结果是否可审计：过滤、裁剪、统计要进入生产链路，就必须说明资源边界、输出一致性和验证路径；
- 集成成本是否可控：很多团队会先用 CLI 验证，再把能力嵌入 C++ 程序或现有 QC 流程，如果接口分裂，采用成本会快速上升。
FastQTools 的价值在于：它把这些问题收敛成同一条白皮书叙事，而不是把“命令说明”“性能数字”“架构取舍”分散在彼此脱节的页面里。若想先抓住当前维护中的阅读主线，可以先看技术白皮书，并把参考导航作为后续命令与 API 的查阅入口。
适用场景
- 需要在预比对阶段稳定完成统计、过滤、裁剪
- 需要批量处理大量 FASTQ 文件，并关注吞吐与资源边界
- 需要先用 CLI 验证，再逐步嵌入 C++ 应用或现有 QC 流程
与同类方案的差异
FastQTools 的差异不在“功能列表更长”，而在它把 零拷贝批处理、并行执行模型、benchmark 证据与长期维护约束 写成同一条叙事链路，方便采用者判断这些主张是否可信。
如果你正在评估“为什么值得采用”，重点不妨放在这三点：
架构明确解释了FastqBatch、std::string_view与source → processing → sink执行路径为什么会影响吞吐和资源边界；性能总览不只是给结论，还告诉你 benchmark 应该怎么读、风险边界在哪里；参考导航与API 概览说明它不是只能停留在 shell 层的一次性命令，而是可以继续下钻到库接口与开发者材料。
这让 FastQTools 更像一个可审查的工程内核，而不只是命令包装器。
不适合谁
如果你的目标更接近下面这些场景，FastQTools 可能不是首选：
- 你需要的是覆盖比对、定量、变异检测等后续阶段的全流程平台；
- 你更在意脚本式插件生态，而不是带有明确资源边界和 C++ API 的核心实现；
- 你只想找一个“什么都做一点”的 FASTQ 杂项工具，而不关心性能证据、维护约束和可嵌入性。
换句话说，不应把它误解成“大而全框架”。它更专注于把 FASTQ QC 的基础动作做扎实、做可解释、做成可被集成和长期维护的能力。