不能直接在 Django View 里跑耗时任务，因为其同步阻塞机制会导致超时、进程被杀、任务不可重试且无法监控；必须用 Celery Canvas（group/chord/chain）编排可切分、幂等、有上下文的小任务，并规避默认配置的五大硬坑。
为什么不能直接在 Django View 里跑耗时任务
因为 Django 的请求响应周期是同步阻塞的，一旦在 view 中执行一个几秒甚至几分钟的任务（比如批量导出万条数据、训练小模型、调用外部慢 API），用户会看到「连接超时」或「504 Gateway Timeout」，而你根本收不到结果——WSGI 服务器（如 Gunicorn）会在超时后强行杀掉 worker 进程，try/except 都拦不住。
更糟的是，这类任务失败后无法重试、无状态、不支持暂停，也不好监控。Canvas 工作流（Celery 的编排机制）不是“锦上添花”，而是处理这类问题的底线方案。
怎么把大 Task 切成可并行的小 Task（chunking）
核心原则：切分依据必须是**可独立执行、无状态、幂等**的数据单元。常见错误是按“时间”或“随机 ID 范围”切，结果导致某 chunk 数据倾斜（比如某个 ID 区间恰好有 90% 的记录），拖垮整个流程。
- 推荐按主键 ID 或时间字段做**等距分片**，例如用
range()+values_list('id', flat=True)拿到全部 ID，再用[ids[i:i+1000] for i in range(0, len(ids), 1000)]切成每批 1000 条 - 避免一次性加载全量 ID 到内存：对千万级表，改用游标式分页，例如
MyModel.objects.filter(id__gt=last_id).order_by('id')[:1000]，配合groupby或递归调用下一个 chunk - 每个子 task 必须接收完整上下文：比如原始请求参数
user_id、export_format，不能只传 ID 列表——否则失败重试时拿不到配置信息 - 切分后不要直接
.apply_async()一千次，改用group()+chord()编排，否则可能压垮 broker（如 Redis 内存溢出）
用 Celery Canvas 实现可靠工作流（group + chord + chain）
group 是并发执行一批同构子任务；chord 是 “group + callback”，即等所有子任务成功后再触发汇总逻辑；chain 是串行依赖，适合前后步骤强耦合的场景（比如「下载 → 解析 → 存库」）。三者嵌套才是真实业务需要的形态。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
示例：导出用户订单报表
from celery import group, chord from myapp.tasks import process_order_chunk, generate_report_summary <h1>切分 ID 列表为 chunks</h1><p>chunks = [[1001,1002,...], [1003,1004,...], ...]</p><h1>并发处理每个 chunk，全部完成后触发汇总</h1><p>workflow = chord( group(process_order_chunk.s(chunk_ids, format='xlsx', user_id=123) for chunk_ids in chunks), generate_report_summary.s(user_id=123, report_id='r_abc') ) workflow.apply_async()</p>
注意：chord 的 callback 任务必须能容忍部分子任务失败（默认只要有一个失败，callback 就不执行）。如需“至少完成 95% 就继续”，得自己在 callback 里查 result.children 状态，再决定是否降级处理。
容易被忽略的五个硬坑
Celery 默认配置在生产环境几乎不可用，Canvas 更放大了这些问题：
-
task_acks_late=True必须开，否则 worker 进程崩溃时未完成的 task 会永久丢失（Django 默认关） - Redis broker 的
visibility_timeout（默认 1h）要大于最长单个子 task 耗时，否则任务会被重复投递 -
chord在 Redis backend 下有已知 race condition：当大量子任务快速完成，callback 可能漏触发——必须换用django-celery-results或PostgreSQL作为 result backend - 子 task 函数不能引用 Django ORM model 类本身（如
Order.objects.filter(...)），而应在函数体内重新 import 或用字符串路径注册，否则热更新后出现PickleError - Canvas 编排本身没有超时控制：如果某个
process_order_chunk卡死，整个chord会永远挂起——必须给每个子 task 显式设soft_time_limit和time_limit
Canvas 不是魔法，它只是把复杂性从代码里挪到了任务调度层。真正难的从来不是怎么切分，而是怎么让每一块都可追溯、可中断、可重入——尤其是当用户中途取消请求时，你还得主动 cancel 对应的 task group，而这需要你保存好 GroupResult.id 到数据库里。
