仿佛轻云兮如敝月单细胞测序数据这几年越来越夸张，动不动就是几万个细胞、几亿条表达矩阵，拿到手的 .h5ad 文件动辄几十个 G，甚至上百 G。很多朋友第一次接触这种文件时以为和 CSV 一样，一行 pd.read_csv 直接读，结果内存瞬间爆炸，笔记本风扇狂转半天后进程被杀。我早几年也踩过这个坑，后来硬着头皮把整个读取、切片、拆分流程梳理了一遍，才摸索出一套比较顺手的处理方式。
本文就围绕“单细胞数据 h5ad 的超大数据分割”这个主题，把我实际在用的方案、选型原因、踩坑记录和详细代码全部整理出来。适合手里有超大单细胞数据文件、想要单机内存受限条件下完成拆分归档、或者准备做下游分析前去做数据规整的朋友参考。内容不仅会讲怎么用 Python 读取 GEO 单细胞数据，还会把面向 h5ad 这种 HDF5 格式的内存映射、稀疏矩阵存储、分块写入这些底层逻辑一次说清楚，尽量让基础不同的读者都能直接上手。
1. 项目背景：为什么单细胞数据文件越来越大
1.1 单细胞数据为何体积膨胀这么快
单细胞测序技术从早期几百个细胞发展到现在 10x Genomics 一次上机就能产出上万个细胞，数据规模的增长是几何级别的。一个标准的表达矩阵，横坐标是基因，纵坐标是细胞，每一个位置记录的是该基因在该细胞中的表达量。光这一张矩阵，假设有 2 万个基因、10 万个细胞，如果以 64 位浮点数存储，理论上就需要 2 万乘 10 万乘 8 字节，大约 16 GB 的原始内存。
但实际文件远比这个复杂。h5ad 格式里除了表达矩阵本体，还要存很多元数据：细胞条码、样本分组、细胞类型注释、UMAP 坐标、标准化参数、基因注释信息等。这些信息虽然单个体积不大，但汇总起来也会占据不小空间。更麻烦的是，单细胞分析过程中经常需要保留中间结果，比如原始计数矩阵、归一化矩阵、对数变换后的矩阵会同时出现在同一个 AnnData 对象里，这会让文件体积继续膨胀。
1.2 h5ad 格式到底能装下什么东西
h5ad 本质上是基于 HDF5 格式封装的一层单细胞数据结构，背后对应的 Python 对象叫 AnnData。AnnData 把数据分成了几个核心部分：
X：主表达矩阵，默认行是细胞、列是基因；obs：细胞注释信息，DataFrame，保存样本分组、批次、细胞类型等；var：基因注释信息，DataFrame，保存基因名、染色体位置、基因类型等；obsm：细胞层面的降维坐标，例如 PCA、UMAP、TSNE 的结果都在这里；varm：基因层面的降维坐标；uns：非结构化信息，存一些图谱参数、聚类参数、配色信息等；layers：额外的表达矩阵，可以同时维护多个版本的计数数据。
看到这个结构就能明白，直接拿 pandas 去读一个几十 G 的 .h5ad 是行不通的，因为 pandas 没有针对 HDF5 做内存映射机制，全部数据必须一次性加载进 RAM。要处理超大数据文件，就得从 AnnData 的底层设计入手，利用 HDF5 的分块存储和内存映射特性。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计与思路拆解：先想清楚再动手
2.1 分割前必须明确的三个维度
在动手写代码之前，我先会问自己一个问题：用户真正想要的是“文件变小”，还是“内存能装下”？
这两个目标对应的方案完全不同。如果只是想让文件变小，可以用压缩参数存成 .h5ad.gz，或者在保存时调整 compression 等级。单细胞表达矩阵里绝大多数元素是 0，使用 gzip 或 lz4 压缩后文件体积能缩小到原来的十分之一甚至更小。但如果目标是让程序能跑起来、能在内存里操作，那就必须做分割，把一个大 AnnData 对象拆成多个小对象。
围绕分割，需要先确定三个维度：
- 按细胞分割：根据
obs里的分组字段，如疾病对照、组织部位、细胞类型，把数据切成若干子集； - 按基因分割：根据
var里的染色体编号或基因类型，把表达矩阵沿着基因维度切块； - 按批次分割：把来自不同测序文库或不同实验批次的数据分离开，方便后续做批次校正或独立分析。
我会在工程里同时支持三种维度，但默认优先按细胞分割，因为下游分析一般以细胞作为最小分析单元，基因层面往往需要全基因集做后续的差异分析或富集分析，切成小块反而不好处理。
2.2 技术选型：内存映射、稀疏矩阵、增量写入
超大数据分割的难点集中在三个方面：读入时不能把全部数据一次性塞进内存、切分过程中不能产生中间大对象、写回时不能整体序列化造成内存暴涨。
解决方案分别是：
- 使用 AnnData 的
backed模式，这个模式不会把数据全部加载到内存，而是通过文件指针按需读取磁盘上的数据块； - 使用稀疏矩阵格式，单细胞表达矩阵的稀疏度通常都在 90% 以上，用
scipy.sparse里的csr_matrix或csc_matrix存储可以大幅减少内存占用； - 使用 HDF5 的增量写盘能力，通过
h5py逐块写入数据，而不是构建出完整矩阵后再写。
我在实际项目中采用的组合是 scanpy.read_h5ad(..., backed="r") 做按需读取，配合 scipy.sparse 处理切片后的稀疏矩阵，最后用 adata.write_h5ad() 将分割后的子集单独存盘。
2.3 为什么我最终选择了 AnnData + Scanpy 这套组合
我知道有人会问：为什么不直接使用 h5py 手动读取 HDF5 数据？
答案是：可以，但没必要。h5ad 虽然底层是 HDF5，但内部结构被 AnnData 重新组织过，里面的数组存储方式、属性键、索引顺序都遵循 AnnData 自己的约定。直接拿 h5py 读，意味着你要手动解析 obs、var、X 的存储关系，还得自己处理稀疏矩阵压缩格式、编解码规则，实现成本非常高。
Scanpy 是单细胞数据分析的事实标准工具包，它对 h5ad 的读写有全套的底层优化。用 scanpy.read_h5ad 读取时，它会自动识别 HDF5 里存的是稠密矩阵还是稀疏矩阵，并给出对应的数据类型。再加上 Scanpy 生态中有大量针对单细胞数据的预处理函数，后续如果想做归一化、聚类、可视化，都可以在分割后的子集上直接继续，不用跨工具转换。
还有一点很关键：AnnData 的 backed 模式并不影响 obs 和 var 的读取。即使 X 矩阵有几十 G，adata.obs 依然会被完整加载进内存，因为细胞注释通常只是几十 MB 级别的 DataFrame。这意味着在做分割决策时，可以先在内存中对所有细胞的元数据做筛选，指定好切分规则，再按索引去磁盘上取相应行。
3. 实操过程与核心环节实现
3.1 第一步：从 GEO 下载数据并用 Python 读取
这里要回答最近很多人在搜的问题：如何用 Python 读取 GEO 单细胞数据。GEO 数据库里的单细胞数据通常有三种形态：
- 原始 fastq 文件，需要自己跑比对定量流程；
- 处理后的表达矩阵（CSV/TXT），直接读入后用
np.array或pd.DataFrame保存； - 已经做成 AnnData 或 Seurat 对象的 h5ad/rds 文件，最省事，直接读取。
如果拿到的是 h5ad 文件，直接用：
python复制import scanpy as sc
adata = sc.read_h5ad("GSE123456_counts.h5ad", backed="r")
print(adata)
如果只是 CSV/TXT 表达矩阵，常规做法是：
python复制import pandas as pd
import scanpy as sc
from scipy import sparse
df = pd.read_csv("GSE123456_counts.csv", index_col=0).T
adata = sc.AnnData(X=sparse.csr_matrix(df.values), obs=df.index.to_frame(), var=df.columns.to_frame())
需要注意，GEO 上传的矩阵经常是基因在行、样本在列，和 AnnData 默认的细胞在行、基因在列不一致。读进来之后先检查维度，别等后面分析出来了才发现方向反了。
提示：优先下载 GEO 里
supplementary file中标注为 sparse 或 h5ad 的版本，这样能省去很多格式转换功夫。
3.2 第二步：快速体检 h5ad 文件，弄清楚分割边界
拿到 h5ad 文件后，我不会急着分割，而是先用几行代码搞清楚内部结构：
python复制print("shape:", adata.shape)
print("obs columns:", adata.obs.columns.tolist())
print("var columns:", adata.var.columns.tolist())
print("layers:", list(adata.layers.keys()))
print("obsm:", list(adata.obsm.keys()))
print("X dtype:", adata.X.dtype)
print("X memory:", adata.X.nbytes)
这个体检过程非常重要，很多问题在分割之前就能暴露出来。
比如，如果 adata.X 的 dtype 是 float64，而无损表达计数用 float32 或者 int32 就足够了，完全可以先把 dtype 降下来再进行分割，能省一半内存。再比如，如果 layers 里有多个相似矩阵，比如 counts 和 normalized，那么在分割时就必须决定是否需要对每个 layer 都做切片，还是只保留其中一个。我的建议是先从小的 sub-AnnData 开始测试，确认所有结构都能正确切片后再上全量数据，避免中途报错才发现问题。
3.3 第三步：按分组变量对样本进行切分
最常见的分割需求是按样本分组切分成多个文件。比如一个大的数据里同时包含肿瘤和正常样本，我要把这两部分分别保存。
在 backed 模式下，AnnData 支持切片操作，但要注意切片后得到的对象依然持有对原文件的引用，必须要用 to_memory() 或复制出来独立保存。不这么做的后果是，后续如果原文件被修改，切出来的子集数据也会跟着变化，而且无法独立归档。
下面是我实际在用的按组切分代码：
python复制import scanpy as sc
import os
input_file = "GSE123456_counts.h5ad"
output_dir = "split_by_group"
os.makedirs(output_dir, exist_ok=True)
adata = sc.read_h5ad(input_file, backed="r")
groups = adata.obs["disease"].unique()
print("groups:", groups.tolist())
for g in groups:
sub = adata[adata.obs["disease"] == g].to_memory()
sub.write_h5ad(os.path.join(output_dir, f"disease_{g}.h5ad"), compression="gzip")
print(f"group {g}: {sub.shape}, saved")
这里有几个细节值得展开说。
第一，adata[adata.obs["disease"] == g] 先通过布尔索引选出细胞的逻辑位置，AnnData 的切片会同时切 X、obs、var、layers、obsm 等所有结构。切片是在 backed 模式下完成的，所以不会一次性加载全部数据，而是从磁盘上按需读取对应的行块。
第二，.to_memory() 会把切片结果从磁盘映射模式转换到内存对象。对于小的分组，这个操作完全没问题；但如果分组仍然很大，就不建议用 to_memory()，而是直接用 .write_h5ad() 写盘，因为 write 过程自身是按块读取的，不会暴涨内存。
第三，compression="gzip" 会在写入时进行压缩，实测下来文件体积通常能缩小 70% 以上，代价是后续读取时 CPU 占用会高一点。追求速度可以用 compression="lz4"，但 lz4 压缩率不如 gzip。单细胞数据一般侧重存储效率，所以我会优先用 gzip。
3.4 第四步：按基因特征进行切分
按基因切分的需求通常来自两种情况：一是只关心某个染色体区域或某个基因集的表达，二是在做跨数据库整合时先把共同基因筛选出来。
按基因切分的方法和对细胞切分类似，只是在切片索引时选第二维：
python复制# 假设 var 里有基因类型列，只保留编码蛋白的基因
coding_genes = adata.var[adata.var["gene_type"] == "protein_coding"].index
sub = adata[:, coding_genes].to_memory()
sub.write_h5ad("protein_coding_only.h5ad", compression="gzip")
还有个常见坑是基因名重复。GEO 数据在整理时经常出现同一个基因符号对应多个 Ensembl ID，或者多个基因符号被归并成同一个名称。切片之前务必先检查：
python复制print(adata.var.index.duplicated().sum())
如果有重复，建议先做去重，否则切片结果会出现行数对不上、后续分析结果不可复现的问题。我常用的去重策略是保留平均表达量最高的那个：
python复制import numpy as np
if adata.var.index.duplicated().any():
dup_rows = adata.var.index[adata.var.index.duplicated(keep=False)]
print("Duplicated genes:", dup_rows.tolist()[:20])
# 对每个重复基因保留表达均值高的，需要先把矩阵转为稠密做均值，代价较大
# 或者简单方案：直接保留第一个
adata = adata[:, ~adata.var.index.duplicated(keep="first")]
提示：基因名版本问题非常常见。GEO 上有些数据用的是 Ensembl ID，有些是 Symbol，有些是夹杂版本号的 Ensembl ID。建议从 GEO 下载备注表，统一映射到你的目标基因名体系后再切分。
3.5 第五步：用 h5py 对超大规模矩阵做底层分割
前面介绍的 Scanpy 做法适合一般场景，但如果单个 h5ad 文件已经大到连 backed 模式都会频繁触发磁盘 I/O 瓶颈，或者原始数据不是 h5ad 而是纯 HDF5 文件，那就需要直接用 h5py 做底层操作。
我的一个项目里曾经拿到过一个 120 GB 的 HDF5 文件，里面只有一个巨大的稠密矩阵，没有任何细胞注释信息。遇到这种数据，我通常是先以只读方式打开文件，用 h5py 的切片能力逐行读取数据块，把大矩阵像切豆腐一样分成固定大小的数据块，然后分别写入不同的目标文件。
示例代码如下：
python复制import h5py
import numpy as np
src_path = "raw_matrix.h5"
dst_dir = "h5_chunks"
os.makedirs(dst_dir, exist_ok=True)
chunk_size = 5000 # 每次读取 5000 行
with h5py.File(src_path, "r") as src:
dataset = src["expression_matrix"]
nrows, ncols = dataset.shape
print("shape:", dataset.shape, "dtype:", dataset.dtype)
for i in range(0, nrows, chunk_size):
end = min(i + chunk_size, nrows)
block = dataset[i:end, :]
dst_path = os.path.join(dst_dir, f"chunk_{i:06d}_{end:06d}.h5")
with h5py.File(dst_path, "w") as dst:
dst.create_dataset("expression_matrix", data=block, chunks=True, compression="gzip")
print(f"chunk {i}:{end} saved")
# 及时释放内存，避免累计
del block
这里 chunk_size 的选择是一个权衡。取值太大会导致单次读取内存高，取值太小则会因为频繁 I/O 导致速度很慢。我一般按目标峰值内存来估算，比如限制单次读取占用内存不超过 1 GB，那么对于 float32 的稠密矩阵，单次读取的细胞数乘以基因数应控制在 2.5 亿以内。实际项目中，如果矩阵是 10 万细胞乘 2 万基因，我一般一次读 5000 行，内存占用大约是 5000 乘 20000 乘 4 字节，也就是 400 MB，运行起来比较稳。
直接操作 h5py 的优势是绕开了 AnnData 的所有中间层，适合处理不是由 Scanpy 生成的 HDF5 文件；缺点是数据会丢失原有的结构信息，切出来的就只是矩阵，没有细胞注释。因此这个方案只作为最后的兜底手段。
3.6 第六步：校验分割结果并独立保存
分割完成后，不能直接收工，一定要做校验。我见过不少人切完文件后，后面分析时才发现某个分组里细胞数和原始元数据对不上，排查半天才发现是切片索引写错了。
我会写一个简单的校验脚本，对每个输出文件重新读取基础信息，并和原文件的 obs 分组统计做对照：
python复制import scanpy as sc
import pandas as pd
original = sc.read_h5ad(input_file, backed="r")
orig_counts = original.obs["disease"].value_counts()
for f in os.listdir(output_dir):
if f.endswith(".h5ad"):
ad = sc.read_h5ad(os.path.join(output_dir, f))
grp = f.replace("disease_", "").replace(".h5ad", "")
print(f, ad.shape)
print("orig count:", orig_counts.get(grp, 0))
print("new count:", ad.shape[0])
这里要注意，adata.shape[0] 是细胞数，切片后应该和原文件里对应分组的细胞数完全一致。同时我还会检查输出文件里的 var 列数是否等于原来的基因数，如果某个分组文件里基因数变了，多半是切片时不小心切到了基因维度。
校验通过之后，再把文件整理归档。通常我会把输出目录结构固定为：
text复制split_result/
├── 00_raw_check_report.json
├── disease_normal.h5ad
├── disease_tumor.h5ad
└── merge_script.py
其中 00_raw_check_report.json 存的是原文件的分组统计、数据维度、dtype 等摘要信息，这样后续别人拿到这个目录时，不用重新读原始大文件就能知道整个数据的构成。
4. 常见问题与排查技巧实录
4.1 内存直接被打满：backed 模式没有生效
很多人反馈说开了 backed="r" 后内存还是爆了，这个问题几乎都是因为后续操作把数据重新导入了内存。backed="r" 模式只在读取和切片时按需加载，但只要随意执行了访问 adata.X 某个全部数据块、或者调用带全矩阵计算的函数，内存就会立刻暴涨。
排查思路很简单：检查代码里有没有对 adata.X 做直接赋值、有没有调用 sc.pp.normalize_total(adata) 这类全量计算函数。backed 模式基本只能做读取和切片，如果需要做计算，必须先把需要计算的部分用 to_memory() 加载进内存。所以我的流程一般是：先切片，再把切出来的子集转成内存对象，之后才做分析。
4.2 切片之后稀疏矩阵消失了
AnnData 切片后的 X 类型和切片前的原数据类型有关。如果原文件里的 X 是 scipy.sparse.csr_matrix，切片后一般还是稀疏矩阵。但如果原文件存的是稠密矩阵，切片后也不会自动变成稀疏矩阵，这会导致内存快速膨胀。
建议在保存前统一做一次检查：
python复制from scipy import sparse
if not sparse.issparse(sub.X):
sub.X = sparse.csr_matrix(sub.X)
还可以用 repair 思路处理 h5ad 里常见的稀疏矩阵格式不一致问题。有些数据在处理过程中会把 X 从 csr 换成 csc，后续再做切片时效率差异明显。按行切片应使用 csr，按列切片应使用 csc，如果同时需要两种操作，我通常统一转成 csr，因为按组切分的需求远多于按基因切分。
4.3 用 Python 读取 GEO 数据时报矩阵维度错误
GEO 的单细胞表达矩阵下载下来后，第一行第一列经常是空的标签，导致 pd.read_csv 把索引列名解析错误。解决方法是显式指定 index_col=0，同时考虑表头可能是空字符串的情况。
还有一个容易忽略的点是：GEO 矩阵里的值经常是 log 标准化后的数据，有时还会包含负值。如果你的下游分析需要的是原始 count，那读取 GEO 数据后先不要直接做分割，要先去确认表达量单位。把 log 数据当成 counts 处理，后面所有差异分析结果都会失真。
4.4 分割后的子集文件还是很大
如果分割后的子集因为细胞总数仍然庞大而继续保持大体积，这时可以考虑更细粒度的切分，或者启用更强的压缩参数。另外检查 layers 里是不是同时存了多个矩阵，有些数据会有好几个 layer，切分保存时其实可以只保留核心 layer。
写入时还可以调整 HDF5 的 chunk 参数：
python复制sub.write_h5ad("out.h5ad", compression="gzip", compression_opts=9)
compression_opts 是 gzip 压缩等级，从 0 到 9，等级越高体积越小但写入速度越慢。我实测下来 6 是性价比最高的档位，9 虽然体积能再小 10% 左右，但耗时可能增加一倍。
4.5 切分过程中的索引错位
AnnData 的切片是基于索引标签而不是位置。这意味着如果 obs_names 有重复，或者 obs_names 不是唯一索引，切片结果可能会出乎意料。在开始分割前，我先运行：
python复制assert adata.obs_names.is_unique
assert adata.var_names.is_unique
如果这里报错，就不能直接切片，必须先统一索引。常见的做法是加后缀：
python复制adata.obs_names = [f"{b}-{i}" for i, b in enumerate(adata.obs_names)]
5. 工具选型与代码封装建议
5.1 数据读取和保存的基础注意点
做单细胞大数据分割，核心工具就是 scanpy、anndata、h5py、scipy。这几个包的版本兼容性直接影响运行稳定性。我个人的建议是使用 conda 创建一个独立环境，直接把整个工具链锁在一个版本组合里：
bash复制conda create -n scrna python=3.10
conda activate scrna
pip install scanpy anndata h5py scipy pandas numpy
版本尽量选新一点的，scanpy 对最新 anndata 的兼容性通常更好。对于超大文件，我还会额外安装 dask，它可以把切片任务分发到多核上并行执行，尤其适合按多个分组同时输出文件的场景。
5.2 封装一个通用的分割函数
在实际项目中，我会把整个流程封装成函数，避免每次换数据都重写一遍。下面给出一个我在自己项目里使用的基础版本：
python复制import os
import scanpy as sc
import numpy as np
from scipy import sparse
def split_h5ad_by_obs(
input_path,
group_col,
output_dir,
compression="gzip",
compression_opts=6,
max_memory_gb=4,
):
os.makedirs(output_dir, exist_ok=True)
adata = sc.read_h5ad(input_path, backed="r")
# 检查索引唯一性
assert adata.obs_names.is_unique, "obs_names contains duplicates"
assert adata.var_names.is_unique, "var_names contains duplicates"
# 获取分组以及对应细胞索引
groups = adata.obs[group_col].astype(str).unique()
all_names = adata.obs_names
for g in groups:
mask = (adata.obs[group_col].astype(str) == g).values
idx = all_names[mask]
sub = adata[idx, :].to_memory()
# 确保稀疏
if not sparse.issparse(sub.X):
sub.X = sparse.csr_matrix(sub.X)
out_name = f"{group_col}_{g}.h5ad"
out_path = os.path.join(output_dir, out_name)
sub.write_h5ad(out_path, compression=compression, compression_opts=compression_opts)
print(f"{out_name} saved: {sub.shape}")
print("All groups processed.")
用法很简单：
python复制split_h5ad_by_obs("GSE123456_counts.h5ad", "disease", "output_split")
如果你同时想保存每个分组对应的样本和基因列表，可以在函数里加一步导出到 JSON 或 CSV，方便后续索引和复查。
5.3 大数据切分时的并行优化
当分组数量非常多时，例如按照样本名拆分成几百个文件，改成并行会让速度提升非常明显。可以用 joblib 的 Parallel 配合 delayed 来并行处理不同分组。但要注意，并行切割意味着每个并行任务里都要重新 read_h5ad 一次原文件，这样做不仅不会节省 I/O，反而可能因为频繁读取同一大文件导致磁盘 IO 争抢。更合适的做法是：原文件只读一次，在拿到索引列表后，把“读取子集”和“写盘”这两个操作拆开放到多个子进程里，让每个子进程分别通过文件句柄读取各自需要的磁盘区域。
用 Python 的多进程实现这类并行时，建议在启动每个子进程后重新打开 h5ad 文件，而不是传递一个父进程已经创建好的 AnnData 对象，后者很可能在 pickling 过程中因为不支持而报错。这也是我踩过的坑之一。
6. 实操心得：这套流程还能怎么扩展
分割完成不是终点，后续大概率还会有这些扩展需求，我简单分享一下我的做法。
第一，如果分割之后要做批次整合，建议在分割时把原始批次信息保留在 obs 里，不要只留下一个分组列。像是 sample_id、batch、donor 这类列在后续整合时非常关键，提前留下来能少走很多弯路。
第二，如果原始 h5ad 文件里面已经包含 raw 属性，也就是原始未被标准化的数据，那么分割后对应的每个子文件也建议保留 raw。如果在切片时发现 raw 不是自动跟着切，需要手动重建：
python复制sub.raw = sub
之所以建议保留 raw，是因为很多下游分析如差异表达、轨迹推断，都要求输入原始的 counts 数据，一旦丢了再想恢复成本非常高。
第三，对于超大数据，建议把中间输出格式统一确定为 .h5ad，避免中间保存为 CSV。CSV 不仅体积更大，还会丢失稀疏矩阵和元数据层级结构。我见过有人为了在 Excel 里查看表达矩阵特意导出 CSV，结果 5 G 的 h5ad 导出一个多小时，导出的 CSV 达到 40 多 G，Excel 打开就会直接卡死。
第四，磁盘空间规划也要提前考虑。超大 h5ad 文件分割过程中，原文件、中间临时文件、最终输出文件会同时存在，磁盘占用可能达到原文件的三倍以上。我每次开始大数据处理前，会先用 df -h 确认磁盘剩余空间，低于原文件体积 5 倍的情况下坚决不跑。
第五，如果操作系统是 Windows，路径处理上要格外小心。HDF5 里保存的路径是 POSIX 风格，非常容易在 Windows 上因为反斜杠导致路径解析错误。建议所有文件路径统一用 pathlib.Path 管理，并显式转为字符串。
这套流程我已经在好几个超过 50 G 的单细胞数据文件上实际跑过，分割后单个文件基本控制在 1~2 G 范围内，后续无论是加载做可视化还是做差异分析，都顺畅许多。分割的过程虽然整体机械，但每一步都藏着若干小坑，只要把检查点做足、把索引和格式先理清楚，就能把这份体力活变成一套可复用的流水线。希望这篇文章能给正在被超大 h5ad 文件折磨的朋友一些参考。