Celery worker断点不命中，因默认fork子进程导致调试器仅附着主进程；须用--pool=solo禁用多进程、module模式启动celery、justMyCode设为false，并确保worker与任务发送端使用同一Python解释器环境。
VSCode 调试 Celery 任务不能靠“右键运行”或直接 celery -A tasks worker 启动——那样调试器根本 attach 不上，断点全灰、变量不可查、print() 都比断点可靠。
为什么 Celery worker 启动后断点不命中？
Celery 默认以子进程（fork 或 prefork 模式）启动 worker，而 VSCode 的 Python 调试器只 attach 到主进程；即使你用 --pool=solo 强制单线程，若未显式启用 debugpy 或配置 justMyCode，断点仍被跳过。
- 常见错误现象：
Breakpoint ignored because generated code not found或断点图标变空心灰色 - 根本原因：VSCode 启动的是 shell 命令，不是 Python 进程；Celery worker 实际由
celery.bin.celery入口驱动，非用户代码直启 - 必须让 worker 进程本身被 debugpy 注入，而非在外部“监听”它
正确启动可调试的 Celery worker（推荐 solo 模式）
不用改项目结构，也不依赖 celery --loglevel=info 这类纯日志方式——目标是让 VSCode 真正控制 worker 进程生命周期。
- 在
launch.json中添加新配置，不要复用 "Python: Current File"： -
"module": "celery"—— 必须用模块模式启动，否则program指向脚本会绕过 Celery 的命令解析逻辑 -
"args": ["-A", "tasks", "worker", "--loglevel=info", "--pool=solo"]——--pool=solo是关键，禁用 fork，确保所有任务在主线程执行，断点才可命中 -
"justMyCode": false—— Celery 的任务分发逻辑在celery/app/task.py等内部模块，设为true会跳过你的@app.task函数入口 -
"console": "integratedTerminal"—— 否则input()类阻塞或日志输出会丢失
示例最小可用配置：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
{
"name": "Celery Worker (solo)",
"type": "python",
"request": "launch",
"module": "celery",
"args": ["-A", "tasks", "worker", "--loglevel=info", "--pool=solo"],
"justMyCode": false,
"console": "integratedTerminal"
}
调试实际任务函数时要注意路径和导入
你在 tasks.py 里打了断点，但任务一触发就跳过？大概率是模块路径没对齐，导致 Celery 加载了另一个副本。
- 确认
-A tasks中的tasks是可 import 的模块名，不是文件路径；例如项目结构为src/myapp/tasks.py，则需设"env": {"PYTHONPATH": "${workspaceFolder}/src"} - 避免用相对导入（如
from .utils import helper）在任务函数内——worker 启动时工作目录不一定是src/，容易报ImportError - 如果任务定义在
myapp/tasks.py，但celery -A myapp.tasks worker报错，检查myapp/__init__.py是否存在且未抛异常 - 调试前，在终端手动运行
python -c "import tasks; print(tasks.add)"（替换为你的真实模块），验证 import 路径是否通
发送任务时也要走同一解释器环境
调试 worker 成功 ≠ 调试完整链路。如果你在另一个终端用系统 Python 执行 tasks.add.delay(1,2)，而 worker 用的是 venv，那任务可能进队列但永远不被执行（序列化/反序列化失败或版本不兼容）。
- 发送任务的 Python 进程必须和 worker 使用**完全相同的解释器路径**，包括相同 virtualenv 和包版本
- 推荐在 VSCode 的集成终端中操作：先按
Ctrl+Shift+P→Python: Select Interpreter切到 worker 所用环境，再运行测试脚本 - 测试脚本开头加
import sys; print(sys.executable)，和左下角状态栏显示的路径比对是否一致 - 别依赖
celery inspect active判断任务是否入队——它只看 broker 状态；真正要看的是 worker 终端是否打印Task tasks.add[xxx] received
最易忽略的一点：Celery 的 task_serializer 和 result_serializer 默认是 json，但如果你在任务函数里传了 datetime 或自定义对象，又没配 accept_content=['json']，worker 会静默丢弃任务——断点当然不会亮，连日志都不报错。
