打开FastQC报告，左侧连续出现红叉，很多人第一反应是“这批数据不能用了”。但FastQC的红、黄、绿只是按通用阈值触发的提示，不知道你的建库类型、研究目标和下游方法。RNA-seq开头碱基比例不均、small RNA重复度高、亚硫酸氢盐测序C/T比例异常，都可能是实验设计带来的预期现象。
真正有用的判断不是数红叉，而是回答三个问题：异常发生在哪个位置？多个模块是否指向同一个原因？它会不会影响后续比对、定量或变异检测？
版本、输入和输出先核对
本文于2026年11月13日核对FastQC官方资料，当前最新发布版为0.13.0。这个版本的启动脚本改用Python 3，要求Python 3.7及以上、Java 8及以上；线程模型也已更新，单个FASTQ最多可使用4个线程，并能并行处理多个文件。旧教程里“一个线程只对应一个文件”的经验不能直接套到0.13.0。
FastQC可读取FASTQ，也支持SAM/BAM。常见原始数据直接运行：
mkdir -p fastqc_out
fastqc --threads 8 --outdir fastqc_out sample_R1.fastq.gz sample_R2.fastq.gz
每个输入文件会得到一个HTML报告和一个ZIP包；解压后可看到机器可读的summary.txt、fastqc_data.txt和图表文件。成对测序的R1、R2要分别检查，不能只抽看其中一个。运行成功至少应满足：命令无解析错误、HTML可打开、Basic Statistics中的文件名与read数符合预期、R1/R2报告齐全。
五个模块，应该怎样联合判断
| 模块 | 官方触发条件（节选） | 看到红黄后先问什么 |
|---|---|---|
| Per base sequence quality | 任一位置下四分位数＜10或中位数＜25警告；下四分位数＜5或中位数＜20失败 | 是末端逐渐下降，还是中间短暂塌陷？后者不宜直接整段剪切 |
| Adapter Content | 任一接头累计出现在＞5% reads中警告，＞10%失败 | 是否从read末端持续上升？插入片段是否短于读长？ |
| Overrepresented sequences | 单条序列＞0.1%警告，＞1%失败 | 匹配的是接头、rRNA、引物，还是预期高丰度生物序列？ |
| Per base sequence content | 任一位置A/T或G/C差异＞10%警告，＞20%失败 | RNA-seq前约12 bp偏倚是否来自随机引物？建库类型是否本来就偏？ |
| Per sequence GC content | 相对拟合正态分布的总偏差＞15%警告，＞30%失败 | 是尖锐污染峰、混合物种宽峰，还是目标生物本身GC偏移？ |
这些阈值适合做统一报警，却不是通用淘汰线。例如FastQC官方说明，几乎所有随机六聚体引物RNA-seq都可能在5′端出现组成偏倚，这通常不能靠剪切“修好”，也未必妨碍表达定量。相反，如果质量尾部下降、Adapter Content同步上升、Overrepresented sequences又命中接头，三个模块共同支持“存在接头读穿”，再考虑剪切就更有依据。
一套可复用的诊断顺序
第一步，先看Basic Statistics与Sequence Length Distribution。确认文件不是空的、read长度符合平台与剪切历史、R1/R2数量和命名没有混乱。基础信息错了，后面的红绿没有解释价值。
第二步，看Per base sequence quality和Per tile sequence quality。末端缓慢变差常见于长读长化学质量衰减；如果只在某些tile出现局部低质量，更像测序面板问题。官方提示，中段短暂掉质后又恢复时，直接从该点截断会误删后面仍然良好的序列。
第三步，把Adapter Content、Overrepresented sequences和碱基组成放在一起。接头曲线从后半段累积上升，才支持read-through；单一高丰度序列还要结合污染物匹配和实验类型解释。FastQC只跟踪前100,000条read中出现的序列用于过表达统计，报告没有命中也不等于完全不存在污染。
第四步，按同一批次比较样本。单个RNA-seq样本5′端偏倚可能正常，但若只有一个样本GC分布出现额外尖峰、接头比例明显偏离其他样本，就值得回查建库与样本身份。批量项目可用MultiQC汇总FastQC结果，但原始判断仍应回到FastQC单样本曲线。
第五步，处理前后各跑一次。剪切后应关注接头曲线是否下降、长度分布是否符合预期、低质量尾部是否改善；不能只追求全部变绿。过度剪切会缩短read、丢失有效信息，甚至引入新的末端组成偏倚。
批量运行时，建议把输入清单、软件版本、命令和退出状态一起留存，而不是只保留HTML。下面的写法可避免输出目录缺失，并把标准输出和错误信息写入日志：
mkdir -p fastqc_raw logs
fastqc --threads 8 --outdir fastqc_raw data/*.fastq.gz \
> logs/fastqc_raw.log 2>&1
test $? -eq 0 && echo "FastQC finished"
如果样本很多，先用2—4个文件做小批试跑，观察CPU利用率、磁盘读写和单文件耗时，再决定并发数。完成后检查输入FASTQ数、HTML数和ZIP数是否一致；缺一份报告就应先定位失败文件，不能把“多数样本完成”当成整批成功。之后再用MultiQC生成项目级总览，并保留异常样本的原始FastQC报告用于追溯。
交付或换机器复跑时，还应保留输入文件校验值与FastQC版本号。这样既能区分“数据发生变化”和“软件环境发生变化”，也方便在下游结果异常时回到原始质控证据，而不是重新猜测问题从哪一步开始。
哪些情况本地够用，何时再上服务器
两三个FASTQ、文件不大、只需人工查看HTML时，本地电脑通常足够。先把版本、命令和判读标准固定，比直接增加硬件更重要。FastQC也不是GPU软件，换显卡不会解决质控问题。
当项目有几十到上百个压缩FASTQ、需要原始与剪切后两轮质控、还要长期保留HTML、ZIP、日志和汇总结果时，瓶颈更常在磁盘吞吐、并发调度与稳定运行。此时服务器的价值是让批量任务不受笔记本休眠影响，统一FastQC版本和目录结构，并按文件数与I/O能力控制并发；不要把线程数无限开大，否则多个gzip解压任务会互相争抢磁盘。
FastQC能报警，但不能替你下结论
FastQC不会自动修剪，也不能证明污染来源；过表达序列的数据库匹配只是方向提示。它还不知道你的建库策略，因此small RNA、扩增子、RNA-seq、ATAC-seq和亚硫酸氢盐测序不能用同一套“全绿”标准。最终决定应结合实验类型、同批样本、剪切前后变化以及下游比对率、插入片段和定量表现。
如果FastQC批量报告难以判断，可以准备：FastQC版本、测序类型、样本数与文件大小、一个可分享的HTML或模块截图、计划的下游分析和完成期限。云生信可先协助判断是参数与流程问题、需要统一服务器环境，还是适合在约定范围内委托完成批量质控与后续分析；租用服务器自行运行与委托分析的范围分别确认。
