同步操作会阻塞事件循环，导致其他协程无法调度；正确做法是将阻塞操作移出主线程，如用asyncio.sleep()替代time.sleep()、用run_in_executor处理CPU密集任务、用异步库替代requests等同步I/O。
同步逻辑本身不会直接阻塞异步任务队列的执行，但若在异步上下文中不当混用同步操作，就可能间接拖慢甚至“冻结”整个异步调度流程。
同步代码会抢占事件循环或线程资源
在单线程异步环境（如 Python 的 asyncio 或 JavaScript 的 Event Loop）中，异步任务依赖事件循环来轮询、调度和执行。一旦某个协程或回调里执行了耗时的同步操作（比如 time.sleep(2)、文件读写、CPU 密集型计算），它就会独占当前线程，导致事件循环无法及时切换到其他待处理的异步任务。
- 例如：一个 HTTP 请求触发的异步 handler 中调用了
requests.get()（同步网络请求），整个事件循环将卡住，其他 pending 的协程全部暂停； - 再如：在 Node.js 中用
fs.readFileSync()替代fs.promises.readFile()，也会阻塞主线程，使后续定时器、I/O 回调延迟执行。
同步逻辑可能阻塞任务入队或出队过程
很多异步任务队列（如 Celery、RabbitMQ 客户端、Redis 的 pub/sub 消费者）本身运行在独立进程或线程中，但它们的生产者逻辑若同步且缓慢，会影响任务提交节奏：
- 前端 API 接口用同步方式批量生成 1000 个任务并逐个调用
task.delay()，而每个.delay()内部涉及网络序列化+发送，若未并发/异步提交，整体耗时拉长，队列“看起来”响应变慢； - 消费者端若在处理一条消息时执行同步数据库事务（如 Django ORM 的
.save()），且该事务锁表时间长，会导致该 worker 进程无法及时拉取下一条消息，队列积压加剧。
关键不是“队列被阻塞”，而是“调度能力被削弱”
异步任务队列（如 Celery 的 broker + workers）本身是解耦的，队列服务（如 Redis/RabbitMQ）不执行业务逻辑，所以它不会被同步代码阻塞。真正受影响的是：
- 生产者端：提交任务慢 → 入队速率低；
- 消费者端：worker 进程/线程忙于同步操作 → 处理吞吐下降 → 出队变慢；
- 调度中枢（如事件循环、线程池）：被同步代码霸占 → 无法及时分发新任务。
如何避免同步逻辑干扰异步队列
核心原则是：让耗时操作远离调度主线程，交由专用机制处理。
- 网络 I/O 改用异步客户端（
aiohttp/httpx.AsyncClient/axios）； - 文件操作使用异步 API（
asyncio.to_thread()包装阻塞调用，或aiofiles）； - CPU 密集任务丢给进程池（
concurrent.futures.ProcessPoolExecutor），避免阻塞 event loop； - 数据库操作启用异步驱动（
asyncpg、aiomysql、Django 5.0+ async views）； - 在 Celery 中明确标注
@task(bind=True, acks_late=True)，防止 worker 因异常中断导致任务丢失。
