先确认现象是否由中断亲和性引起：ESP32的WiFi协议栈和LWIP任务默认跑在Core0（PRO_CPU），WiFi硬件中断也默认绑定Core0。若你把应用任务固定到Core1，同时把WiFi相关中断也迁移或让高优先级任务长期占用Core1，就会挤压中断服务与协议栈处理，表现为响应变慢。定位步骤：1) 用esp_timer或GPIO翻转测中断到任务唤醒的延迟；2) 检查configMAX_SYSCALL_INTERRUPT_PRIORITY与任务优先级，确认没有在临界区长时间关中断；3) 用vTaskGetRunTimeStats看Core1是否有高优先级忙等任务；4) 确认未在Core1调用阻塞式WiFi API。取舍建议：WiFi中断和协议栈保持Core0，应用实时任务放Core1并留出足够优先级余量；若必须迁移中断，需评估WiFi吞吐与实时性的平衡，优先保证中断响应而非任务并行度。