零代码也能做RNA-seq：Galaxy平台全流程实操指南

测序数据拿到手，最常见的状态不是马上分析，而是原地发懵。文件后缀认识几个，知道 fastq 是原始序列，但接下来要装什么软件、跑什么流程、怎么看结果，完全没有抓手。论坛里的答案又总是绕不开 Python、R 和 Linux，仿佛不先硬啃小半年代码，这数据就永远只能躺在硬盘里。

实际情况没那么极端。标准测序分析里，绝大多数高频流程已经被封装成图形界面或网页工作流：公共 Galaxy 平台注册就能用，桌面端有 TBtools 这种双击就开的工具，课题组有服务器还能本地部署一套 Galaxy。质控、去接头、比对、定量、差异表达，这些核心环节都不强制写代码。

这篇文章就解决一件事：在你还没准备好学代码之前，怎么把已有的测序数据变成能看、能汇报、能继续讨论的结果。我会给出方案选型、部署方式、一套完整的免代码 RNA-seq 测试流程、批量任务与接口调用方法，以及最常踩的坑。下面所有流程都按“先小数据试通、再看结果、再批量化”的思路展开，具体参数和资源占用以实际工具版本和本机环境为准。

1. 测序数据分析核心方案速览

先把能用的方案放在一张表里，方便你根据手头条件直接选。测序数据分析这件事，如今已经不是一个“必须写代码”的领域，而是一个“按需求选工具”的领域。

本文重点围绕 Galaxy 展开，因为它同时覆盖了“免代码”和“批量任务”两个核心需求。TBtools 作为桌面补充工具，适合处理小文件和画图，这两者可以搭配使用。

从这个表能看出来，免代码并不等于功能缩水。Galaxy 这类平台把工具封装成了标准化模块，把参数暴露在表单里，本质上和命令行工具的选项一一对应，只是不需要你在终端里敲命令。

2. 免代码方案的适用场景与使用边界

免代码方案最适合这几类人：

• 生信零基础，需要尽快得到差异基因、变异注释等结果。
• 湿实验课题组，几十个样本要统一跑一套流程。
• 教学、培训和课题预实验，需要快速演示完整分析链路。
• 临床或转化场景的初筛，但前提是数据合规与安全边界已经确认。

如果你的目标是把一个标准流程跑完并拿到结论，免代码方案的效率远高于先学语法再写脚本。但有些场景不适合硬用免代码方案，需要提前认清边界：

• 要做全新算法、非标准分析流程时，图形界面没有对应工具。
• 数据规模极大，又受公共站点配额限制时，公共平台跑不动。
• 想长期做生信研发、需要频繁调试和二次开发时，脚本语言是绕不开的。
• 需要极其精细控制每一步参数时，命令行仍然更直接。

数据合规边界必须放在选方案之前考虑。人源、患者、临床样本等敏感数据，原则上不应直接传到公共服务器。公共数据库的数据要遵守对应数据使用条款。工具和脚本要遵从开源许可，不要随意二次分发未授权代码。发表研究成果时，按期刊要求写清楚工具名称和版本。

3. 测序数据分析环境准备与前置条件

3.1 公共 Galaxy：零安装，但先确认配额

用公共 Galaxy 分析，你只需要一个浏览器和一个邮箱。注册账号后就能进入分析工作台，上传数据、选工具、看结果都在网页上完成。

实际操作前要确认两件事：文件上限和存储配额。公共站点通常会给免费账号提供基础存储空间和作业队列，但不同站点政策不一样，具体以站点公告为准。测序原始文件建议统一压缩成 .fastq.gz 再上传，既节省空间也加快传输。

3.2 本地部署 Galaxy：准备服务器与 Docker

如果数据不允许出内网，就需要本地部署 Galaxy。建议先准备一台 Linux 服务器，Windows 用户可以用 WSL2 作为运行环境。硬件方面，内存和磁盘是关键：参考基因组、索引、中间 BAM 文件都很占空间。具体配置没有统一答案，建议先用小数据测算峰值占用，再决定是否扩容。

bash复制# 检查 Docker 是否可用，命令通用
docker --version

3.3 TBtools：先解决 Java 环境

TBtools 是 Java 写的桌面程序，前提条件是本机有可用的 Java 运行时。启动前先检查一下：

bash复制java -version

如果提示找不到 java，就先安装对应版本的 Java。不同版本的 TBtools 对 Java 版本要求可能不同，优先看工具包里的说明文件。

3.4 命令行“备胎”：装一个最小生信环境

强烈建议在机器上备一个最小命令行环境，不一定现在就用，但某个小工具只有 CLI 版本时能救急。Windows 上先用 WSL2 装 Linux，再装 conda：

bash复制# 创建最小生信环境（模板命令，包名可按需增删）
conda create -n bio -y python=3.11
conda activate bio
conda install -c bioconda -c conda-forge fastqc fastp

这里的 bio 环境平时可以不用，遇到 Galaxy 和 TBtools 都覆盖不了的小功能时，再临时安装对应工具即可。

4. 三套免代码入口的安装部署与启动方式

4.1 公共 Galaxy：注册即用

公共 Galaxy 平台的入口很多，不同站点由不同团队维护，账号、存储、作业队列各自独立。操作路径基本一致：

1. 打开公共站点，注册账号，邮箱激活。
2. 进入分析页面，左侧是工具面板，中间是历史记录。
3. 上传测序文件，建议使用 .fastq.gz 压缩格式。
4. 在工具搜索框输入工具名，设置参数并运行。

公共站点适合快速验证流程是否可行。要注意，有些站点作业需要排队，部分资源型工具有运行时限，不要一次性提交超大任务。

4.2 本地 Galaxy：Docker 部署

本地部署不是“双击完成”的操作。首次启动会拉取镜像并初始化工具依赖，需要等待较长时间。这里给一个通用模板，实际镜像名、版本、挂载目录请以 Galaxy 官方部署文档为准：

bash复制# 模板示例：拉取镜像并启动容器
docker pull galaxyproject/galaxy:latest

docker run -d --name galaxy-local \
  -p 8080:80 \
  -v /srv/galaxy_data:/export \
  galaxyproject/galaxy:latest

启动后浏览器访问 http://127.0.0.1:8080。如果 8080 端口被占用，就改成其他端口，比如 -p 8090:80，然后访问对应地址。首次初始化时不要急着操作，先看容器日志确认服务就绪。

bash复制# 查看本地容器日志（模板命令）
docker logs -f galaxy-local

4.3 TBtools：桌面双击启动

TBtools 使用起来最简单：下载 jar 包或对应平台运行包后，双击即可打开。命令行方式也可以：

bash复制# 手动启动 TBtools，前提是已安装 Java
java -jar TBtools.jar

启动后主要用三类功能：序列提取、格式转换、图形绘制。比如从 GFF 文件里提取基因上游启动子序列，或者把表格整理成基因结构图，这类操作在 TBtools 里都是菜单点击完成。

4.4 什么时候才需要转命令行

当你遇到以下情况，才需要考虑命令行：工具只有 CLI 版；需要对成百上千个文件做循环；需要把流程放进定时调度或 CI。对大多数单次分析来说，公共 Galaxy 或本地 Galaxy 已经够用，不必提前焦虑。

5. 免代码跑通 RNA-seq 全流程的功能测试与效果验证

下面以 RNA-seq 差异表达这条最常见流程为例，串一遍免代码操作。Galaxy 工具面板里直接搜索工具名，就能看到封装好的模块。参数给出的是通用值，实际请按项目调整。

5.1 准备一份测试数据

先用公共测试数据或手头一个小样本文件做验证，不要一上来就提交全量数据。双端测序文件建议保持成对命名，比如 sample_1.fastq.gz 和 sample_2.fastq.gz，方便后续工具自动识别。

5.2 第一步：原始数据质控 FastQC

在 Galaxy 搜索栏输入 FastQC，选择测序文件，运行即可。预期输出是一个 HTML 报告和一个结果 zip 包。

判断结果是否正常的参考点：

• 碱基质量曲线主体应处于绿色区域。
• GC 含量曲线没有明显异常偏移。
• 没有大量过度代表序列或接头序列。

如果 FastQC 报告打不开，多半是下载不完整或浏览器渲染问题，把 zip 下载到本地再解压打开。

5.3 第二步：去接头与低质量过滤 Trimmomatic / fastp

质控发现问题后，用 Trimmomatic 或 fastp 做清洗。Trimmomatic 的常用参数大概是这样，按界面字段对应填写：

text复制# Trimmomatic 常用参数模板（按实际界面字段调整）
ILLUMINACLIP:adapters.fa:2:30:10
SLIDINGWINDOW:4:20
MINLEN:50

预期输出是修剪后的双端/单端 fastq 文件，以及过滤统计报告。重点看保留了多少数据：如果过滤后只剩不到一半，要考虑建库质量或参数是否过严。

5.4 第三步：比对到参考基因组 HISAT2 / STAR

选择工具后，先选物种和参考基因组版本。常见物种在 Galaxy 里会提供内置索引，自定义物种需要自行上传索引或构建。比对后输出的 BAM 文件和比对摘要日志，可以直接在页面上查看。

判断标准：常见正常建库的 RNA-seq 样本比对率通常在 80% 以上，但具体取决于物种、组织、RNA 完整度和参考基因组版本。低于合理范围时先回到质控环节查原因，不要急着调工具参数。

5.5 第四步：基因定量 featureCounts

featureCounts 输入比对后的 BAM 和 GTF/GFF 注释文件，输出基因表达计数矩阵。验证标准很简单：矩阵的行是基因，列是样本；每个样本的 counts 总和应该和测序量大致对应。

5.6 第五步：差异表达 DESeq2

DESeq2 在 Galaxy 中有封装好的模块。输入计数矩阵和实验设计信息，运行后输出差异基因表、MA 图和 PCA 图。

验证结果时注意三点：PCA 图中重复样本是否按实验分组聚集；差异基因数量是否符合实验预期；显著差异基因是否在文献中有对应结论。

5.7 效果验证清单

一个完整流程是否跑通，可以按下面清单对账：

• 每个环节都产生了预期输出文件，没有红色报错。
• 比对率在合理区间。
• 样本 PCA 按实验分组聚集。
• 差异基因数量与实验设计一致。
• 关键差异基因能通过 IGV 或桌面工具做二次确认。

5.8 用 TBtools 做辅助验证

有些验证不一定要重跑流程。TBtools 可以从结果文件里提取序列、转换格式、画基因结构图。比如对 top 差异基因做启动子序列提取，或者把差异表直接画成热图，这类收尾工作用桌面工具更顺手。

6. 批量任务与接口 API 调用

6.1 工作流与数据集集合

Galaxy 的核心优势是工作流。把 FastQC、Trimmomatic、比对、定量、差异表达串成一个工作流，之后每个新样本都复用同一套流程。多个样本可以用数据集集合（Collection）作为输入，一次提交批量运行。

这样做的好处是可复现。工作流文件可以导出发给同事，也可以用同一工作流重新跑一遍，确保参数完全一致。

6.2 Galaxy REST API 基础

Galaxy 提供 REST API。先在用户设置里生成 API Key，然后可以用 curl 直接调用。下面是一个查询历史列表的通用模板，实际接口地址以部署版本为准：

bash复制# 查询历史列表的通用模板
curl -s -H "Authorization: Bearer YOUR_API_KEY" \
  "http://127.0.0.1:8080/api/histories"

返回结果是 JSON 数组，包含每个历史的 id、名称、创建时间等字段。注意 API Key 等同于账号凭证，不要提交到公开代码仓库。

6.3 Python bioblend 调用示例

Python 生态有 bioblend 这个官方维护的 Galaxy 客户端库，适合做批量调用。

python复制# 需要先安装：pip install bioblend
import bioblend.galaxy

gi = bioblend.galaxy.GalaxyInstance(
    url="http://127.0.0.1:8080",
    key="YOUR_API_KEY"
)

# 创建历史并输出 id
result = gi.histories.create_history(name="batch-demo")
print(result["id"], result["name"])

这只是最基础的调用。bioblend 还支持上传数据集、运行工具、获取任务状态等操作，具体方法名和参数以对应版本文档为准。把这段代码当模板，就能把“网页上点一遍”的动作变成“程序批量跑”。

6.4 批量任务的工程化建议

先单样本全流程验证成功，再批量扩展。输出目录按样本名分开，避免互相覆盖。批量脚本要记录日志、失败重试、跳过已完成任务。公共站点要注意配额和作业排队，本地部署要注意磁盘空间和并发任务数。

7. 资源占用与性能观察方法

7.1 公共平台的资源模型

公共 Galaxay 的计算资源在服务器端，用户侧主要瓶颈是上传速度、存储配额和作业队列。上传前先把 fastq 压缩成 .gz，能明显缩短传输时间。运行中如果任务排太久，查看任务状态是 queued 还是 running。

7.2 本地 Galaxy 容器的资源观察

本地部署时，比对、定量、差异检验这些步骤才是吃内存的大头。建议先用小样本跑一遍，用 Docker 自带命令观察峰值：

bash复制# 观察本地容器占用的通用命令
docker stats galaxy-local

如果发现内存持续接近上限，就减小输入数据量或降低并发任务数。参考基因组索引可能占用大量内存，尤其 STAR 这类工具，内存不够时优先考虑换用 HISAT2。

7.3 TBtools 与 WSL2 的资源设置

TBtools 比较轻量，但绘制大文件或处理长序列时也会吃内存。Java 程序可以用 -Xmx 参数增大堆内存，例如 java -Xmx8g -jar TBtools.jar。

Windows 用户使用 WSL2 运行本地 Galaxy 时，可以通过 .wslconfig 文件限制或扩大 WSL2 的资源：

toml复制# Windows 用户在 .wslconfig 中调整 WSL2 资源（按物理内存调整）
[wsl2]
memory=16GB
processors=8

修改后执行 wsl --shutdown 再重启 WSL2 才会生效。

7.4 降低资源占用的一般思路

数据先压缩再上传；正式跑之前用低深度小样本验证；大面积基因组比对可以按染色体拆分；避免同时提交多个大任务。资源占用没有固定数字，和工具版本、数据量、参考基因组大小直接相关，能做的就是观察和调参。

8. 常见问题与排查方法

排查顺序建议：先看日志，再看输入文件，再看参数，最后查工具版本。不要盲调参数。公共站点优先看任务状态与配额，本地环境优先看内存、磁盘和端口。

9. 最佳实践与合规边界

9.1 工程化习惯

测序分析项目建议采用统一目录结构：

• raw_data：原始测序文件，只读不改。
• clean_data：质控和过滤后的文件。
• results：最终结果和图表。
• scripts：脚本、工作流文件、参数配置。
• docs：实验记录、版本信息、问题记录。

文件名统一用 项目_样本_重复_数据类型 的命名方式，比如 project1_sampleA_rep1_R1.fastq.gz。每次跑完记录工具版本、关键参数、参考基因组版本。这三点是后续复现和发表论文的基础。

9.2 数据安全与合规

涉及人源、患者、可定位到个体的数据，不能上传到公共 Galaxy。临床数据应在本地部署环境中分析，并做好访问权限控制。使用公共数据库数据要遵守对应数据使用协议。使用第三方工具、脚本和参考数据时，遵守开源许可和版权约定。

对于测序数据分析，尤其是 RNA-seq、变异检测、宏基因组注释这类能反推个体特征的分析，必须在数据来源合法、授权明确的前提下操作。

9.3 结果审慎与二次验证

免代码流程跑出来的结果不能直接当作最终结论。差异基因需要看生物学意义，关键位点要用 IGV 人工核对比对情况，重要结果要通过实验验证。发表前务必写清楚每个软件名称、版本号、参考基因组版本和白参数设置。

10. 总结与下一步

如果你只是需要尽快完成一批测序数据分析，现在就可以不硬学代码。核心路线很清晰：公共 Galaxy 注册账号，上传 .fastq.gz 数据，把 FastQC、过滤、比对、定量、差异表达跑通，拿到差异表和图表。数据敏感就切换到本地 Docker 部署。

最先要做的验证是一套公开的 RNA-seq 小样本全流程。五个环节全部输出确认无误后，再考虑批量和接口调用。

最容易踩的坑有三个：参考基因组版本选错、上传前不压缩数据、本地部署时内存不足。这三类问题占了新手交流区很大比例，遇到先按第八节的表格排查。

后续如果想长期做生信，建议按这个顺序补课：先学 10 个常用 Linux 命令和日志查看，再学 R 基础绘图，最后再决定深度学 Python 还是 R。这比一上来硬啃代码快得多，也和目前“工具先跑通、语言按需学”的思路一致。建议收藏备用，下次拿到测序数据直接按这份清单操作。