Part 1 做完你應該已經用兩塊 ESP32/ESP8266 把 ESP-NOW 的點對點 Hello World 跑通了。能互相發消息確實很爽但等你真的把它放進一個項目里很快就會發現Demo 能跑不代表系統能干活。這一篇我直接講 Part 2 真正該補的東西——從“兩板互發”到“一套能用的系統”具體包括通信拓撲怎么選、數據幀怎么設計、ACK 和重傳怎么實現、低功耗怎么配合以及那些你查文檔都查不到的坑。這篇適合誰如果你已經在單片機上玩過 ESP-NOW或者至少跑通了點對點收發那你讀這篇文章會非常舒服。如果你完全沒接觸過 ESP-NOW建議先把 Part 1 的基礎收發摸一遍再回來看。因為 Part 2 講的不是 API 怎么用而是當你面對“3 個傳感器節點 1 個網關”這種真實項目時怎么把 ESP-NOW 真正用穩。1. 從“兩板互發”到“一套系統”Part 2 不該只講發消息1.1 Part 1 之后你到底卡在哪先說個扎心的事實大部分人在 Part 1 之后用 ESP-NOW 做的第一個真實項目通常不是“多好玩”而是“怎么這么不穩”。我見過太多人跑來問兩個板子放桌面上發消息沒問題隔一堵墻就丟包或者三個節點一起發網關就收不全再或者電池供電的板子一天就耗盡電量。這些問題的根源不是 ESP-NOW 本身不行而是你還在用“點對點收發”的思路去套真實系統。Part 1 教你的是“怎么發出一條消息”但真實項目需要回答的問題遠不止這些誰和誰通信發什么格式的數據消息丟了怎么辦板子沒電了怎么續命所以我給 Part 2 的定義很直接不是“再講幾個 API”而是把 ESP-NOW 放進一個完整場景里補齊它在可靠傳輸、網絡規模、設備能耗上的短板。你真正要學的不是 ESP-NOW 能干什么而是它不能干什么以及你怎么在應用層把它不能干的補上。1.2 ESP-NOW 的能力邊界它到底可靠嗎ESP-NOW 本質上是一種無連接協議。它基于 802.11 數據幀通信雙方不需要“握手”不需要“建立連接”你把數據交給協議層它盡力幫你發出去但對方有沒有收到它不保證。這句話多讀幾遍因為它是整個 Part 2 的核心出發點。ESP-NOW 的定位有點像你在火車站臺上把一張紙條扔給對面的人——如果風不大、距離不遠、中間沒人擋著對方大概率接得住但你不能指望它像掛號信一樣有簽收回執。但 ESP-NOW 也有一個很大的優勢它不需要連接路由器或 AP兩個設備之間可以直接通信。這意味著它的啟動速度和發送延遲都遠低于標準 Wi-Fi非常適合傳感器上報、遙控信號這類短小數據包。同時代價也擺在那里單包最大只有 250 字節ESP32 / ESP8266 都是這個數。沒有內置 ACK 和重傳丟了就真丟了。一端默認只能維護少量 peerESP32 默認 6 個左右可在 menuconfig 里調整ESP8266 更少不是你想連多少就連多少。所有在同一個頻道上的設備都可能收到廣播包但你不能精確知道誰收到了。所以Part 2 要做的事情本質上就是在 ESP-NOW 之上自己用應用層邏輯給它“補課”補 ACK、補重傳、補節點管理、補節能策略。把這套東西想清楚了你的代碼量可能會翻一倍但穩定性也完全不在一個量級。2. 通信拓撲怎么定一對多、多對一與廣播模式的取舍2.1 三種拓撲形態對比很多人 ESP-NOW 玩不轉第一步就不是死在代碼上而是死在拓撲選型上。你心里得先有一張表搞清楚自己要的是哪種結構。拓撲典型場景實現復雜度可靠性是否推薦一對一遙控開關、兩塊板子間通信低中入門可用一對多廣播同一數據發給所有節點低低不建議做需要穩定的場景多對一匯聚多個傳感器節點上報給網關中高首選多對多全互聯、自組網高看實現新手別碰從我個人的項目經驗來說多對一匯聚結構是 ESP-NOW 最舒服的形態。原因很簡單ESP-NOW 本身就不太像一個“網絡協議”它更像一組“點對點數據通道”而網關 節點模式恰好能把這些通道組織成一棵有序的樹。例如你做一個室內環境監測系統3 個 ESP32 節點分別采集溫濕度、CO2、門磁狀態放在不同房間1 個 ESP32 網關負責匯總所有數據上報到局域網。這種情況下每個節點只需要認識一個目標——網關的 MAC 地址網關維護 3 個節點到自身的 peer 關系即可通信模型極其清晰。2.2 廣播發送的隱藏要求關于一對多廣播很多人第一次用 Esper 都有個誤區以為只要esp_now_send()傳一個特殊的 MAC 地址就能自然廣播。實際上不是。在 ESP-NOW 里廣播地址是FF:FF:FF:FF:FF:FF。但你要先把這個地址當成一個普通 peer 添加進去才能發廣播。代碼類似esp_now_peer_info_t peer; memset(peer, 0, sizeof(peer)); uint8_t broadcast_addr[6] {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; memcpy(peer.peer_addr, broadcast_addr, 6); peer.channel 0; // 0 表示用當前 STA/AP 的信道 peer.ifidx ESP_IF_WIFI_STA; peer.encrypt false; esp_err_t ret esp_now_add_peer(peer);esp_now_add_peer成功之后再esp_now_send(broadcast_addr, data, len)才能真的把數據廣播出去。這個“先添加、后發送”的步驟常被教程忽略卻是我見過最常見的廣播失敗原因。但說實話廣播在 ESP-NOW 里的實用性遠沒有想象中高。因為廣播包沒有確認機制你發出去之后完全不知道哪些節點收到了哪些節點沒收到。如果你對一致性有要求比如要同時給所有節點下發參數廣播很難滿足。一旦某個節點沒收到你是沒法感知到的。所以我的建議是廣播只用于低價值、可重復發送的信息比如“網關注冊確認”“開機同步指令”等。真正重要的數據還是走一對一的定向發送。2.3 網關 節點最推薦的多節點架構既然多對一是最佳形態那具體怎么落地我直接給你一套我自己項目里驗證過的架構節點只負責采集數據定時喚醒后發送數據給網關發送完繼續睡。網關常供電一直保持接收狀態收到節點數據后解析、入庫或轉發到服務器。這里的核心在于節點不需要互相認識它們只需要記住網關的 MAC 地址而網關則需要管理一張節點的“白名單”。MAC 地址表管理是很多新手容易忽略的問題。你可以選擇最簡單的方式把各個節點的 MAC 地址寫死在網關 Flash 里。這適合節點數量固定、不會頻繁變動的場景。如果節點數量需要動態增刪我建議在節點端增加一個“注冊流程”節點上電后先發送一個注冊幀包含自己的設備 ID、類型網關收到后回復 ACK并把該節點的 MAC 地址存入 ESP32 的 NVS 持久化存儲里。這樣后續節點每次上報時網關都能識別出它是誰而且斷電不丟失。有人會問網關最多能掛多少個節點這個要根據你的硬件來確定。ESP32 默認的 peer 列表大小是 6 個這并不代表只能連 6 個節點——你可以通過修改 menuconfig 中的CONFIG_ESPNOW_MAX_TOTAL_PEER_NUM來擴大。我實測過ESP32 在管理 20 個 peer 的情況下仍然能穩定工作但前提是你得嚴格控制單次發送的數據量和發送頻率避免 ESP-NOW 內部緩存溢出。ESP8266 的 peer 數量則少得多默認只有 10 個左右我一般不建議拿 ESP8266 做多節點網關。3. 數據幀設計別再用字符串裸奔了3.1 為什么結構體是 ESP-NOW 的最佳搭檔我看過很多 ESP-NOW 示例程序發數據都是拿char數組拼字符串char msg[32]; sprintf(msg, node1,temp25.5,hum60); esp_now_send(broadcast_addr, (uint8_t*)msg, strlen(msg));這種寫法在 Demo 里沒問題但一旦數據字段超過 5 個你就會被自己的字符串解析折磨死——接收端要先找再找,還要處理浮點數精度問題邊緣情況多到你想砸板子。更推薦的方案是直接定義二進制結構體。因為 ESP-NOW 本身就支持發送任意字節數組而把結構體直接轉成字節流不僅發送端不需要逐字段格式化接收端也不需要逐字段解析效率高、錯誤率低。你可以理解為字符串方案是在“寫文本傳輸協議”結構體方案是在“寫 RPC 序列化”后者天生更適合單片機這種資源受限的環境。3.2 一套可直接抄的傳感器數據結構我貼一套我自己在用的傳感器節點數據幀模板你可以直接參考。項目是“多節點溫濕度采集”每個節點周期性上報數據給網關。#pragma pack(1) typedef struct { uint8_t msg_type; // 1:注冊幀 2:數據幀 3:ACK 4:控制幀 uint16_t seq; // 序列號用于去重和排序 uint16_t node_id; // 節點ID網關通過它識別設備身份 uint8_t battery; // 電量百分比0-100 int16_t temperature; // 溫度實際值 原始值 / 100 int16_t humidity; // 濕度實際值 原始值 / 100 uint16_t crc; // 對整個數據幀的CRC校驗值可選 } sensor_data_t; #pragma pack()然后發送端在做數據填充時直接把結構體指針轉成字節指針sensor_data_t data; data.msg_type 2; data.seq next_seq; data.node_id 1; data.battery getBatteryLevel(); data.temperature (int16_t)(temp * 100); data.humidity (int16_t)(hum * 100); data.crc calc_crc16((uint8_t*)data, sizeof(data) - 2); esp_err_t ret esp_now_send(gateway_mac, (uint8_t*)data, sizeof(data));接收端就簡單了直接強轉void on_data(const uint8_t *mac, const uint8_t *data, int len) { if (len ! sizeof(sensor_data_t)) return; // 長度不匹配直接丟棄 sensor_data_t *msg (sensor_data_t*)data; float temperature msg-temperature / 100.0f; float humidity msg-humidity / 100.0f; }注意一個很小但很關鍵的細節temperature和humidity我用了int16_t而不是float。很多新手喜歡直接發浮點數但浮點在不同平臺、不同編譯選項下的內存布局可能有細微差異而且處理起來不如整型直觀。實際工程中最常見的做法是把精度放大 100 倍存成整型接收端再除以 100既省空間又避免浮點比較麻煩。溫度25.53存成2553接收端除以 100 就是25.53完全夠用。3.3 250 字節上限、結構體對齊與 CRC每個要上 ESP-NOW 的初學者都會被 250 字節這個數字教育一遍。官方文檔寫的單次發送最大 payload 是 250 字節這是扣掉 MAC 頭之后留給應用層的空間。所以你不要以為 251 字節也能試一把超了直接返回ESP_ERR_ESPNOW_ARG。那 250 字節會不會不夠用說實話對大多數傳感器上報場景完全夠。一個結構體里有 10 個int16_t才 20 字節離 250 還遠得很。真正會頂到這個上限的往往是你要一次性傳一個較大的配置塊、日志列表、或者固件分包。如果真的到了那個量級我建議優先做字段裁剪和壓縮而不是貿然提升發送頻率。你可以在應用層做分幀比如 1000 字節的分塊數據拆成 4 幀發送每幀帶frame_index和total_frames字段接收端拼包重組。但分幀邏輯要處理丟包和亂序復雜度會上升不少能不用就不用。再說結構體對齊。默認情況下編譯器為了 CPU 訪問效率會在結構體成員之間插入填充字節。同樣是上面那個sensor_data_t不同字段順序可能導致sizeof()結果不同這在發送端和接收端代碼不一致時會造成災難性后果。所以必須用#pragma pack(1)把結構體強制緊湊排列。這個我在代碼里已經寫了屬于必須保留的關鍵字。CRC 校驗要不要加我的建議是數據幀能加就加。雖然 ESP-NOW 底層基于 2.4GHz Wi-Fi 幀理論上無線幀本身有 CRC32 校驗但在復雜的電磁環境下從接收端拿到數據到應用層處理中間也可能出現極低概率的數據損壞。尤其是你要做多跳轉發或拼接幀這種場景CRC 能在應用層幫你擋住最壞的情況。簡單實現可以用 CRC16幾行代碼就能搞定不值得省。4. 可靠傳輸手動補上 ESP-NOW 缺失的 ACK4.1 發送回調里的真相ESP_OK 不代表對方收到這是我覺得整個 Part 2 里最值得單獨寫一段的地方。很多人在用esp_now_send()時有個錯覺只要它返回ESP_OK消息就“發過去了”。但事實是esp_now_send()返回ESP_OK只代表數據成功進入了 ESP-NOW 的發送隊列至于它最終有沒有發出去對方有沒有收到你要靠注冊發送回調來看。void setup_esp_now_send_cb() { esp_now_register_send_cb([](const uint8_t *mac_addr, esp_now_send_status_t status) { if (status ESP_NOW_SEND_SUCCESS) { last_send_success true; } else { last_send_success false; send_fail_count; } }); }ESP_NOW_SEND_SUCCESS表示鏈路層已經把數據包送到空中并且收到了對端的鏈路層確認。注意這里已經有一點隱藏信息了如果發送失敗回調里會拿到ESP_NOW_SEND_FAIL說明這次數據沒能被對方確認。所以你在設計上層協議時要把“發送回調成功”和“業務層收到 ACK”區分清楚。在 Arduino 環境和 ESP-IDF 環境里回調注冊的 API 略有差別但思路一致。ESP-IDF 里用的是esp_now_register_send_cb()Arduino 里的esp_now_register_send_cb()也很類似部分庫會直接用esp_now_set_send_cb()。不管接口名怎么變關鍵事件都是發送結果回來。4.2 序列號、去重與超時重傳的落地代碼可靠的傳輸層通常由三件套組成序列號、去重、超時重傳。先看序列號。每條數據幀都帶一個遞增的seq字段。接收端維護一張“每個節點最近一次收到的 seq 表”如果新到的seq小于等于上次的值就直接丟棄。為什么會有重復因為如果發送端的 ACK 丟了發送端會重傳重傳的數據包如果實際上已經被對方收到了那對方就會收到兩條一模一樣的業務幀。沒有去重機制網關就會把一條傳感器數據重復處理兩次產生臟數據。重傳邏輯我有兩種實現方式看你的代碼風格方式一同步阻塞式等待 ACKbool send_with_retry(const uint8_t *mac, const uint8_t *data, size_t len, uint8_t retries 3) { for (int i 0; i retries; i) { send_ack_received false; esp_now_send(mac, data, len); uint32_t start millis(); while (millis() - start 50) { // 等待接收端回 ACK或者等發送回調更新狀態 if (send_ack_received) return true; delay(1); } } return false; }這種方式簡單直接但它會阻塞主循環不適合需要同時處理多個節點的網關。比較好的做法是把重傳邏輯放到loop()里做一個發送狀態機。方式二非阻塞狀態機typedef enum { SEND_IDLE, SEND_WAIT_ACK, } send_state_t; send_state_t state SEND_IDLE; uint32_t send_start_ms 0; uint8_t retry_count 0; void try_send_data() { if (state SEND_IDLE) { esp_now_send(gateway_mac, (uint8_t*)data, sizeof(data)); state SEND_WAIT_ACK; send_start_ms millis(); retry_count 0; } else if (state SEND_WAIT_ACK) { if (send_ack_received) { state SEND_IDLE; // 成功了 } else if (millis() - send_start_ms 100) { if (retry_count 3) { state SEND_IDLE; // 放棄 } else { esp_now_send(gateway_mac, (uint8_t*)data, sizeof(data)); send_start_ms millis(); } } } }這兩種方式我都用過前者適合節點數少、邏輯簡單的場景后者適合網關這種需要不斷接收多路數據、不能長時間卡住的場景。沒有絕對好壞但你得有個意識超時時間必須比一個完整的發送-確認周期長否則就會做無意義的重傳。我實測過在同一房間、無障礙環境下 ESP-NOW 一發一收的典型延遲在 2ms 到 5ms 左右但如果你中間隔了墻或者附近有藍牙設備干擾延遲可能飆到幾十毫秒。所以重傳超時設在 50ms 到 100ms 都是合理區間再短容易誤判再長會拖累系統吞吐量。4.3 不同業務場景該不該無條件重傳重傳不是越多越好這里有個業務層面的判斷策略。以傳感器上報為例如果節點采集到的溫度是 25.5 度發送時丟包了1 秒后你重傳這包數據那這包數據依然有效。但如果丟包發生在 60 秒之后的重傳那它反映的已經不是當前狀態了可能還不如不發。所以我在做環境監測節點時每個數據幀里會帶一個timestamp字段網關收到后會比較幀時間和當前時間超過 5 秒的數據直接丟棄避免用舊數據覆蓋新狀態。控制指令又是另一套思路。比如設備收到“打開繼電器”指令這種指令不能因為超時就丟棄因為業務上的后果是執行或者不執行舊指令本身沒有時效性但有確定性。所以控制幀必須無條件重傳直到收到 ACK。如果重傳次數超過上限還要向上層拋出異常讓系統進入安全狀態而不是繼續盲目重發。再往下說你還可以做更細的策略比如數據幀每個節點發送時帶上當前值。如果連續兩次采集的數據差異小于閾值就降低發送頻率減少無謂的空中流量。指令幀不依賴節點上報采用“指令 seq 重傳”模式確保執行且只執行一次。注冊幀上電時如果沒收到 ACK就延遲隨機時間重發避免多個節點同時注冊導致網關崩潰。這些策略聽起來高大上但實現起來都是很直白的 if-else核心在于你愿不愿意在設計初期多花一點時間定義好每個幀的語義。等到代碼全部跑起來再回頭改成本要高得多。5. 低功耗組合拳喚醒、發送、繼續睡5.1 為什么電池供電必須用深度睡眠ESP32 和 ESP8266 在 Wi-Fi 保持連接時電流消耗要按幾十毫安到上百毫安來估算。假設一塊 1000mAh 的鋰電池給一個常開 ESP32 供電即使只是待機也就十幾小時到幾十小時就沒了。如果在傳感器上報項目里你要它 24 小時不間斷工作那就是想都不用想必須上深度睡眠。深度睡眠的原理很簡單把芯片大部分外設斷電只保留 RTC 或喚醒邏輯電流可以降到微安級ESP32 深度睡眠典型值約 10μA 左右ESP8266 也差不多具體取決于板卡上的穩壓器。節點采用“定時喚醒 → 發送數據 → 繼續睡”的模式電池壽命能從幾天拉長到幾個月甚至一年。ESP-NOW 在這里有個天然的契合點——它不需要連接路由器所以喚醒后只要初始化 Wi-Fi 協議棧和 ESP-NOW就能在極短時間內把一條數據發出去然后立刻睡回去整個過程可能不到 200ms。5.2 定時上報場景完整流程下面是一個典型的定時上報節點代碼骨架基于 Arduino 框架適用于 ESP32#include WiFi.h #include esp_wifi.h #include esp_now.h uint8_t gateway_mac[] {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; const int SEND_INTERVAL_SEC 60; void setup() { WiFi.mode(WIFI_STA); // 不連接路由器只啟動STA esp_now_init(); esp_now_peer_info_t peer; memset(peer, 0, sizeof(peer)); memcpy(peer.peer_addr, gateway_mac, 6); peer.channel 1; // 固定信道必須和網關一致 peer.ifidx ESP_IF_WIFI_STA; peer.encrypt false; esp_now_add_peer(peer); sensor_data_t data; build_sensor_data(data); esp_now_send(gateway_mac, (uint8_t*)data, sizeof(data)); // 等待發送完成然后深度睡眠 delay(50); esp_sleep_enable_timer_wakeup(SEND_INTERVAL_SEC * 1000000ULL); esp_deep_sleep_start(); }關鍵點有四個節點必須把channel固定確保和網關在同一個信道上。節點可以不調用WiFi.begin()去連接 AP只要WIFI_STA模式初始化完成ESP-NOW 就能工作。深度睡眠前最好留一點延遲確保esp_now_send()的數據已經從協議棧發出去。否則剛發完就睡發送隊列里的數據可能直接被丟掉。esp_sleep_enable_timer_wakeup()的單位是微秒us這點特別容易踩坑我用1000000ULL故意放大給你看避免你看漏單位。ESP8266 的寫法略有不同它用的是ESP.deepSleep(SEND_INTERVAL_SEC * 1000000UL)。但 ESP8266 從深度睡眠喚醒后啟動到能發 ESP-NOW 數據的初始化時間要更長我實測過大概要 1 秒以上所以在選型時如果對低功耗上報延遲要求高優先用 ESP32。5.3 Channel 不一致才是“收不到”的最大元兇這部分我要重點說因為這是我排查過最多的問題而且官方文檔里經常語焉不詳。ESP-NOW 雖然是“無連接”的但它仍然是基于 Wi-Fi 物理層的所有設備必須工作在**同一個信道Channel**上才能互相通信。問題在于ESP32 的WiFi.mode(WIFI_STA)并不等于它一定使用固定的信道——如果某個設備連接了路由器它的信道會與路由器對齊如果沒連接路由器默認信道可能跟其他設備不一致。我舉個非常典型的翻車場景網關通過 WiFi 連接了家里的路由器路由器自動選擇信道 6所以網關的 ESP-NOW 實際在信道 6 上收包。節點只啟動WIFI_STA沒連接路由器默認可能在信道 1 上發包。結果節點發得再開心網關也聽不到因為兩個設備根本不在同一個頻道上。解決方式有兩種。一種是所有設備都固定信道顯式調用esp_wifi_set_channel(1, WIFI_SECOND_CHAN_NONE);在 ESP32 里這行代碼能強制把 STA 接口的信道設為固定值。你需要保證所有節點和網關的channel參數一致。另一種做法是在節點端也調用WiFi.begin()連接同一個路由器利用路由器把信道廣播給所有設備但這樣既增加功耗又違背了低功耗的初衷我一般不推薦。另外說一句ESP32 的esp_now_peer_info_t結構體里也有channel字段。當channel 0時ESP-NOW 會沿用當前 STA/AP 的信道。如果你的板子沒有固定信道就很容易在不同環境下表現不一致。我查過的絕大多數“昨天還能用今天收不到”的問題最后都是信道漂移造成的。所以請在所有 ESP-NOW 設備上把信道寫死沒有例外。6. 常見問題與排查技巧實錄6.1 ESP-NOW 返回值速查表ESP-NOW 的函數尤其是esp_now_init()和esp_now_add_peer()經常返回各種錯誤碼。如果你只把返回值打印成十六進制不看錯誤碼代表什么排查起來會很費勁。這里我整理了一份速查表基本能覆蓋你日常會遇到的坑。錯誤碼含義最常見原因ESP_OK (0)成功無ESP_ERR_ESPNOW_NOT_INIT (0x3001)未初始化忘記調用esp_now_init()或初始化未成功ESP_ERR_ESPNOW_ARG (0x3002)參數錯誤傳入空指針、長度超 250、MAC 地址為空ESP_ERR_ESPNOW_NO_MEM (0x3003)內存不足發送太頻繁內部緩存隊列滿了ESP_ERR_ESPNOW_FULL (0x3004)peer 列表已滿默認 peer 數量已用完需要調整配置ESP_ERR_ESPNOW_NOT_FOUND (0x3005)peer 不存在發送前沒調用esp_now_add_peer()ESP_ERR_ESPNOW_INTERNAL (0x3006)內部錯誤協議棧異常一般重啟可恢復ESP_ERR_ESPNOW_EXIST (0x3007)peer 已存在重復添加同一個 MAC 地址ESP_ERR_ESPNOW_IF (0x3008)接口錯誤當前使用的ifidx與初始化模式不匹配排查思路很簡單哪里報錯先查表而不是去改業務代碼。我遇到過好幾次ESP_ERR_ESPNOW_NOT_FOUND排查到最后才發現是自己把 peer 加進去了但發送時傳了另一個 MAC 地址的指針這種低級但隱蔽的問題只有對著錯誤碼才能快速定位。6.2 排查“收不到”的六步法如果兩個板子之間一直收不到消息別急著在代碼里加各種 Serial 打印看輸出按照這套順序來排查通常五分鐘內能定位問題。第一步確認兩個設備都初始化成功。esp_now_init()返回值必須為ESP_OK如果失敗先看是不是 WiFi 模式沒有正確啟動物理層。第二步確認發送端和接收端的 MAC 地址。在 setup 階段打印WiFi.macAddress()兩個地址確認沒錯再檢查代碼里寫死的peer_addr是否匹配。我看過的問題中“MAC 地址抄錯一位”的比例意外地高。第三步確認 peer 添加成功。發送端必須在esp_now_add_peer()里把接收端 MAC 加進去返回ESP_OK之后再發。不要漏掉這一步也不要忽略返回值。第四步確認信道一致。前面講過了所有設備固定信道通信雙方必須工作在同一個信道。如果之前接過路由器路由器可能會自動調整信道這會讓 ESP-NOW 跟著漂移。第五步確認發送回調。如果esp_now_send()返回ESP_OK但回調里返回ESP_NOW_SEND_FAIL說明數據在物理層實際發送失敗或對方沒有確認。此時重點查信道和距離、遮擋還有是不是同時發太多包導致緩存排隊。第六步用串口打開發送和接收回調日志確認事件是否觸發。很多時候問題不是“沒收到”而是接收回調里被if(len ! expected)之類條件提前干掉了。你不打日志是看不到這一層的。6.3 我踩過的坑和最終的調試習慣最后分享幾個我反復踩過的坑每一個都花過我不少時間。第一個坑是回調里做耗時操作。ESP-NOW 的接收回調是在中斷上下文或非常高頻的軟件線程里執行的如果你在回調里調用Serial.println()輸出一大段日志、或者處理 JSON 解析很可能導致后續消息丟失。我的做法是回調里只把數據拷貝到全局緩存設置一個data_ready標志主循環里再處理。如果你非要打印就用一個短字符串不要拼接。第二個坑是 ESP-NOW 和 Wi-Fi 同時使用時的內存問題。當你的網關既要連路由器又要用 ESP-NOW 時esp_now_init()可能會因為內存不足返回錯誤。遇到這種情況先把 WiFi 連接的 Buffer 調小或者使用 ESP-IDF menuconfig 適當調整CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM多數情況下能解決。如果你用的是 Arduino 框架降低傳輸日志等級CORE_DEBUG_LEVEL也可能釋放一些內存。第三個坑是 ESP8266 和 ESP32 混用時的結構體差異。雖然我都用#pragma pack(1)解決了對齊問題但兩塊芯片的編譯器和默認字節序是相同的這里沒問題。真正要注意的是不同板卡的 WiFi 模式和初始化等待時間不同ESP8266 初始化后如果立即發 ESP-NOW容易出現詭異失敗最好加一個 100ms 的delay()。第四個坑是關于節點“注冊”的。如果你做了網關 節點的動態管理建議讓節點保存自己注冊成功后的回復狀態到 NVS / EEPROM。否則每次斷電重啟節點都會重新向網關注冊網關那邊又要處理重復注冊邏輯。我是在網關側維護一張“已注冊 MAC 最后活躍時間”的表收到重復注冊就刷新時間而不是直接丟棄這樣節點異常重啟后還能繼續工作。我最終的調試習慣是每個 ESP-NOW 設備在 setup 階段打印自己的 MAC、信道、peer 數量、最近一次發送/接收狀態。信息多了不丟人等項目跑通之后你可以再把這些日志關掉或者降級。調試 ESP-NOW 最痛苦的不是代碼邏輯而是無線信道、物理環境這些你“看不見”的變量你只有把報文狀態暴露出來才能快速排除變量。沒有打印日志習慣的人往往要浪費好幾天在一行代碼上反復試錯。Part 2 的內容到這里基本講完了。我個人在實際操作中最深的體會是ESP-NOW 就像一把好用的短刀它能砍能切但你不能把它當瑞士軍刀用。它沒有 ACK、沒有重傳、沒有中心化管理員這些本來就不是它的強項。你只要學會在應用層把這些缺失補上它就是物聯網廉價設備之間通信最高效的方案之一。如果你正準備做一個多節點采集系統先從“一個網關 3 個節點”的最小原型開始把信道固定、結構體定義、ACK 和重傳這四個基本功打扎實后面無論怎么擴展都不會慌。