.NET后台任务崩溃在99%？这个切片策略能救场

100万条数据，跑到第99万条时进程崩溃——你选重跑3小时，还是手动修复？这个.NET开发者最痛的场景，有个更干净的解法。

切片重排：把"大石头"切成"小石子"

核心思路很简单：不一次性吞下整批任务，而是切成固定大小的小块（比如每块100条），处理完一块再拿下一块。失败时只重试当前切片，而非全部。

代码层面，用Chunk()方法（分批处理）配合队列的Enqueue()（入队）实现自循环。前一个切片处理完，自动把下一片塞进队列尾巴。内存只扛得住100条，而非100万条。

原文作者给出的C#示例很直白：读取数据→按100条切片→处理→把剩余切片重新入队。没有复杂状态机，没有分布式事务，就靠队列本身的可靠性兜底。

为什么"简单循环"在量产环境必崩

本地测试能跑通的代码，上线后暴露三个硬伤：

第一，内存爆炸。ORM（对象关系映射）框架默认会追踪实体变化，百万级对象驻留内存，GC（垃圾回收）压力直接拉满。

第二，失败成本极高。单进程单循环，任何异常导致前功尽弃。作者吐槽："跑到第99,999条失败，你重试整个任务？"

第三，无法横向扩展。一个进程扛所有，加机器也没用，因为任务状态锁死在内存里。

切片策略的隐藏收益：解锁云原生弹性

切成小片后，系统获得三个实战级能力：

故障隔离。单个切片失败，重试范围锁定在100条，不会污染已处理数据。配合幂等设计（重复执行结果一致），可以做到"任意点崩溃，任意点重启"。

弹性伸缩。队列里的切片可以被任意数量的消费者并行捞取。流量高峰时加容器实例，低谷时缩到单机，成本随负载波动。

可观测性。每个切片是一个独立作业，日志、指标、链路追踪粒度天然细化。定位"哪批数据出问题"从翻GB级日志变成看队列状态。

这个模式不适合谁

切片重排不是银弹。作者提醒：如果你的任务有强顺序依赖（比如后一条数据依赖前一条的计算结果），或者切分本身成本极高（比如需要跨网络拉取原始数据），这个策略反而增加复杂度。

它最适合的场景是" embarrassingly parallel "（天然可并行）——大量独立记录，彼此无依赖，失败可重试。报表生成、数据清洗、图片转码这类任务，是典型靶子。

判断标准：能否接受"第50片比第49片先完成"？能，就用；不能，再想办法。

落地建议：从现有队列系统开始

不需要推翻重来。Hangfire、RabbitMQ、Azure Service Bus 这些.NET生态常见队列，都支持手动入队。改造路径是：把原来的大循环，换成"切片→处理→剩余切片入队"的三段式。

关键配置：切片大小。太大失去弹性，太小队列开销占比过高。作者建议从100-1000条区间试起，监控内存和队列深度调优。

另一个细节：幂等键。切片入队时带上批次ID+偏移量，确保同一切片被多次处理时，下游能识别并去重。这是"可重试"的前提。

后台任务的可靠性，往往不取决于代码多优雅，而取决于失败时丢多少进度。切片重排把"全有或全无"变成"局部可控"，这个思维迁移到任何需要处理大规模数据的场景都成立。