1. 为什么我选择用ESP8266做点对点无线传输
如果你手头有两块ESP8266模块，想让它们互相传数据，比如一块采集温湿度、另一块接收后显示或者上传，那你大概率会先想到用MQTT或者HTTP。这两种方式确实成熟，但前提是你得有个路由器、有个服务器，或者至少有个能跑Broker的机器。可很多时候我们面对的场景根本没这么理想——比如在野外做数据采集、在移动设备之间传指令、或者单纯就是想省掉中间环节，让两块板子直接对话。
这时候点对点无线传输就是最直接的路子。ESP8266本身支持Wi-Fi，可以工作在Station模式（连别人的热点）、AP模式（自己当热点），或者AP+Station共存模式。利用这些模式组合，我们完全可以让一块ESP8266当服务端（Server），另一块当客户端（Client），通过TCP或UDP协议直接通信，不需要任何外部网络基础设施。
我最初接触这个方案是为了做一个远程控制的小项目：一块ESP8266接传感器放在阳台，另一块接继电器放在室内，两者之间隔了两堵墙，直线距离大概十五米。用路由器中转当然可以，但路由器放在客厅，阳台信号只有两格，偶尔会掉线。后来改成一块ESP8266开AP，另一块直接连上去，信号反而更稳，因为距离更近、路径更直接。这个经历让我意识到，在很多小规模、短距离的场景里，点对点直连比走基础设施更可靠。
这篇文章我会把整个实现过程拆开讲清楚：从模式选择、协议取舍，到服务端和客户端的代码结构，再到实际调试中会遇到的坑。代码部分我会用Arduino框架来写，因为这是大多数爱好者最熟悉的开发方式。如果你用的是RTOS SDK或者MicroPython，思路完全一样，只是API调用方式不同。
注意：ESP8266的Wi-Fi是2.4GHz频段，穿墙能力一般，但胜在功耗低、成本低。如果你的场景需要更远距离，可以考虑外接天线或者改用其他方案，但本文只讨论ESP8266本身的能力边界。
2. 服务端与客户端模式的核心差异与选型逻辑
2.1 AP模式与Station模式的本质区别
ESP8266的Wi-Fi模块有两种基础工作模式，理解它们的区别是做好点对点传输的前提。
Station模式（STA）就是让ESP8266去连接一个已有的Wi-Fi热点，就像手机连路由器一样。在这个模式下，ESP8266是一个客户端设备，它需要知道目标热点的SSID和密码。连接成功后，路由器会给它分配一个IP地址，它就可以和同一网络里的其他设备通信了。
AP模式（Access Point）则是让ESP8266自己变成一个热点，其他设备可以来连接它。这时候ESP8266就是网络中心，它负责给连入的设备分配IP地址（通过DHCP或者手动指定）。AP模式下ESP8266的默认IP通常是192.168.4.1，连入的设备会被分配到192.168.4.x的地址段。
那在点对点传输里怎么选？我的经验是：谁需要被连接，谁就开AP；谁主动去连，谁就用STA。举个例子，如果一块ESP8266要持续发送传感器数据，另一块要接收并处理，那发送方可以开AP，接收方用STA去连它。反过来也行，取决于你的数据流向和哪块板子更方便供电。
但这里有个细节很多人会忽略：ESP8266可以同时工作在AP和STA共存模式。这意味着它可以一边连着一个路由器上网，一边自己开热点让其他设备连进来。这个模式在需要“透传”的场景里非常有用——比如一块ESP8266从传感器收集数据，通过STA模式上传到云平台，同时通过AP模式让手机直接连上来查看实时数据。
2.2 TCP还是UDP：一个容易被轻视的选择
选完模式，接下来要决定用TCP还是UDP。很多人默认用TCP，因为“可靠”，但在ESP8266的点对点场景里，这个选择需要更仔细地权衡。
TCP是面向连接的协议，它保证数据按顺序到达、不丢失、不重复。代价是需要三次握手建立连接，有确认重传机制，头部开销也更大。在ESP8266上，TCP连接会占用更多内存，而且如果连接意外断开，需要重新建立。
UDP是无连接的，发出去就不管了。它不保证到达、不保证顺序，但胜在轻量、快速、内存占用小。对于传感器数据这种“偶尔丢一两个包无所谓”的场景，UDP反而更合适。
我做过一个对比测试：两块ESP8266相距十米，一块每秒发送一次100字节的数据包，连续发1000次。TCP模式下，平均延迟是12毫秒，内存占用约4.2KB；UDP模式下，平均延迟是3毫秒，内存占用约1.8KB。UDP丢了7个包，但对温湿度这种变化缓慢的数据来说，完全不影响使用。
所以我的建议是：如果数据需要严格可靠（比如控制指令、文件传输），用TCP；如果是周期性传感器读数、状态广播，用UDP更划算。当然，你也可以在UDP之上自己加一层简单的确认机制，兼顾轻量和可靠。
2.3 服务端与客户端的角色分配
在TCP通信里，服务端和客户端的角色是固定的：服务端监听某个端口，等待客户端来连接；客户端主动发起连接。这个模型在ESP8266上很清晰。
服务端要做的事：初始化Wi-Fi（AP模式或STA模式），创建TCP Server对象，监听指定端口（比如8080），然后不断检查是否有客户端连入。一旦有客户端连入，就建立一个新的连接对象，通过这个对象收发数据。
客户端要做的事：初始化Wi-Fi（STA模式），创建TCP Client对象，用服务端的IP和端口发起连接。连接成功后，就可以通过这个对象收发数据了。
这里有个实际经验：服务端最好能同时处理多个客户端连接。ESP8266的Wi-Fi模块理论上支持5个左右的TCP连接，但实际测试中，超过3个连接后稳定性会下降。如果你的场景需要多个客户端，建议在应用层做轮询或者让客户端分时上报。
UDP模式下没有“连接”的概念，服务端和客户端的区分没那么严格。通常的做法是：一方绑定一个本地端口，另一方往这个端口发数据。谁先发谁后发都可以，但需要知道对方的IP和端口。
3. 服务端固件的完整实现与关键细节
3.1 环境准备与基础库选择
我用的开发环境是Arduino IDE，配合ESP8266核心库。如果你还没装，去开发板管理器里搜索“esp8266”安装即可。版本建议用3.0以上，对Wi-Fi稳定性和内存管理做了不少优化。
需要包含的头文件很简单：
#include <ESP8266WiFi.h> #include <WiFiClient.h> #include <WiFiServer.h>这三个就够了。ESP8266WiFi库提供了Wi-Fi连接和AP管理的API，WiFiServer用来创建TCP服务端，WiFiClient用来处理每个客户端连接。
如果你要用UDP，把WiFiServer和WiFiClient换成WiFiUDP即可：
#include <WiFiUdp.h>3.2 AP模式服务端的搭建步骤
先看AP模式。服务端开热点，客户端来连。代码结构如下：
#include <ESP8266WiFi.h> #include <WiFiClient.h> #include <WiFiServer.h> const char* ssid = "ESP_Server"; const char* password = "12345678"; WiFiServer server(8080); void setup() { Serial.begin(115200); WiFi.softAP(ssid, password); IPAddress myIP = WiFi.softAPIP(); Serial.print("AP IP address: "); Serial.println(myIP); server.begin(); Serial.println("Server started"); } void loop() { WiFiClient client = server.available(); if (client) { Serial.println("New client connected"); while (client.connected()) { if (client.available()) { String data = client.readStringUntil('\n'); Serial.print("Received: "); Serial.println(data); client.print("Echo: "); client.println(data); } } client.stop(); Serial.println("Client disconnected"); } }这段代码做了几件事：设置AP的SSID和密码，启动AP，打印AP的IP地址（默认192.168.4.1），启动TCP服务端监听8080端口。在loop里不断检查是否有客户端连入，有的话就读取数据并回显。
几个关键点：WiFi.softAP()的密码至少8位，否则会失败。server.available()返回的是一个WiFiClient对象，如果当前没有客户端连接，这个对象是空的（布尔值为false）。client.connected()判断连接是否还在，client.available()判断是否有数据可读。
注意：
readStringUntil('\n')会一直读到换行符为止。如果你的客户端发送的数据里没有换行符，这个函数会一直阻塞直到超时。所以客户端发送时最好在末尾加上\n。
3.3 Station模式服务端的搭建步骤
如果服务端要连现有的路由器，把AP部分换成STA连接：
const char* ssid = "YourRouter"; const char* password = "YourPassword"; void setup() { Serial.begin(115200); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println(""); Serial.print("Connected to "); Serial.println(ssid); Serial.print("IP address: "); Serial.println(WiFi.localIP()); server.begin(); }STA模式下，ESP8266从路由器获取IP地址，客户端也需要连到同一个路由器才能通信。这种方式的好处是可以接入互联网，坏处是依赖路由器。
3.4 多客户端连接的处理策略
前面的代码一次只能处理一个客户端。如果要支持多个客户端同时连接，需要维护一个客户端列表：
#define MAX_CLIENTS 3 WiFiClient clients[MAX_CLIENTS]; void loop() { WiFiClient newClient = server.available(); if (newClient) { bool added = false; for (int i = 0; i < MAX_CLIENTS; i++) { if (!clients[i] || !clients[i].connected()) { clients[i] = newClient; added = true; Serial.print("Client added to slot "); Serial.println(i); break; } } if (!added) { Serial.println("No free slot, rejecting client"); newClient.stop(); } } for (int i = 0; i < MAX_CLIENTS; i++) { if (clients[i] && clients[i].connected() && clients[i].available()) { String data = clients[i].readStringUntil('\n'); Serial.print("Slot "); Serial.print(i); Serial.print(": "); Serial.println(data); clients[i].print("ACK\n"); } } }这个模式用固定大小的数组管理客户端，每个槽位存一个WiFiClient对象。新客户端连入时找空槽，找不到就拒绝。轮询每个槽位检查是否有数据。实测下来，3个客户端同时连接时，ESP8266的内存占用大约在12KB左右，还算宽裕。
但要注意：如果某个客户端异常断开（比如断电），connected()可能不会立刻返回false，需要过几秒才会更新。所以实际项目中，我建议加一个心跳机制——客户端每隔几秒发一个心跳包，服务端超过一定时间没收到就主动断开该连接。
4. 客户端固件的编写与连接稳定性优化
4.1 客户端连接服务端的基本流程
客户端的代码比服务端简单一些，核心就是连Wi-Fi、连服务端、收发数据：
#include <ESP8266WiFi.h> #include <WiFiClient.h> const char* ssid = "ESP_Server"; const char* password = "12345678"; const char* serverIP = "192.168.4.1"; const int serverPort = 8080; WiFiClient client; void setup() { Serial.begin(115200); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println("\nWiFi connected"); Serial.print("Client IP: "); Serial.println(WiFi.localIP()); } void loop() { if (!client.connected()) { Serial.println("Connecting to server..."); if (client.connect(serverIP, serverPort)) { Serial.println("Connected to server"); } else { Serial.println("Connection failed"); delay(2000); return; } } client.println("Hello from client"); delay(1000); if (client.available()) { String response = client.readStringUntil('\n'); Serial.print("Server response: "); Serial.println(response); } }这段代码里，client.connect()是阻塞的，默认超时时间比较长。如果服务端没开，客户端会卡在这里很久。实际使用中建议用非阻塞方式或者设置超时：
if (!client.connect(serverIP, serverPort, 2000)) { Serial.println("Connection timeout"); return; }第三个参数是超时时间，单位毫秒。设成2000就是2秒，超过就返回失败。
4.2 断线重连与心跳保活
无线连接最怕的就是莫名其妙断开。ESP8266在信号弱、干扰大的环境里，TCP连接可能几分钟就断一次。所以客户端必须有断线重连机制。
我常用的做法是在loop里检查client.connected()，如果返回false就重新连接。但要注意，connected()有时候会“假死”——连接实际上已经断了，但它还返回true。这时候需要配合心跳机制：
unsigned long lastHeartbeat = 0; const unsigned long heartbeatInterval = 5000; void loop() { if (!client.connected()) { reconnect(); return; } if (millis() - lastHeartbeat > heartbeatInterval) { client.println("PING"); lastHeartbeat = millis(); } if (client.available()) { String response = client.readStringUntil('\n'); if (response == "PONG") { // 心跳正常 } } }服务端收到PING后回复PONG。如果客户端连续几次没收到PONG，就主动断开重连。这个机制在长时间运行的项目里非常必要。
4.3 客户端发送数据的格式设计
数据格式看起来是小事，但设计不好后面会很麻烦。我踩过的坑是：一开始用纯文本，字段之间用逗号分隔，比如25.6,60.2,1013.25。后来发现如果某个字段缺失或者包含逗号，解析就会出错。
后来改成JSON格式：
String payload = "{\"temp\":25.6,\"humi\":60.2,\"pres\":1013.25}"; client.println(payload);JSON的好处是结构清晰、扩展方便，加字段不影响旧代码解析。坏处是ESP8266上解析JSON需要额外的库（比如ArduinoJson），会占用一些内存。如果你的数据量很小、字段固定，用逗号分隔也够用，但一定要在协议里约定好字段顺序和数量。
还有一种更省事的做法：用二进制格式。比如把三个浮点数直接打包成12个字节发送。这样最省带宽，但调试起来不直观。我一般只在数据量特别大或者对延迟要求极高的场景才用。
5. 实测中遇到的典型问题与排查过程
5.1 连接不上：从信号强度到IP配置的逐项排查
第一次调试时，客户端死活连不上服务端。串口打印显示Wi-Fi连上了，但client.connect()一直返回失败。排查过程如下：
第一步，确认服务端的AP是否真的启动了。用手机搜了一下，能看到“ESP_Server”这个热点，说明AP没问题。
第二步，确认客户端的IP地址。串口打印显示客户端拿到了192.168.4.2，和服务端的192.168.4.1在同一网段，没问题。
第三步，确认端口。服务端监听的是8080，客户端连的也是8080，没问题。
第四步，用ping测试。在客户端代码里加了一段ping服务端IP的代码，发现能ping通。说明网络层是通的。
第五步，怀疑是防火墙或者端口被占用。但ESP8266上不存在这些问题。
最后发现是服务端代码里server.begin()之后没有加delay，客户端连得太快，服务端还没完全准备好。在server.begin()后面加了一个delay(100)就好了。
这个坑让我明白：ESP8266的Wi-Fi栈初始化是异步的，WiFi.softAP()返回成功不代表热点已经完全就绪。加个小延时是最简单的解决办法。
5.2 数据丢包与延迟波动的应对
UDP模式下丢包是常态，但TCP模式下如果出现丢包，那就有问题了。我遇到过TCP连接下数据偶尔丢失的情况，排查后发现是发送频率太高导致的。
当时客户端每10毫秒发一次数据，服务端处理不过来，缓冲区满了就丢数据。解决办法有两个：一是降低发送频率，改成每100毫秒发一次；二是增大服务端的接收缓冲区，但ESP8266的内存有限，这个方案不太现实。
后来我改成客户端每50毫秒发一次，服务端每次loop只读一个包，问题就解决了。实测下来，50毫秒的间隔在ESP8266上非常稳定，连续跑24小时没有丢包。
延迟波动方面，TCP的延迟通常在10到30毫秒之间，偶尔会跳到100毫秒以上。这通常是因为Wi-Fi信道拥堵或者ESP8266在后台处理其他任务（比如DHCP续租）。如果对延迟敏感，可以考虑用UDP，并且把数据包控制在100字节以内。
5.3 内存不足导致的崩溃与优化
ESP8266的内存是有限的，可用堆内存大约40KB左右。如果代码里大量使用String对象，很容易造成内存碎片，最终导致崩溃。
我遇到过一次：服务端运行几个小时后突然重启，串口打印显示“Fatal exception 28”。查了一下，是内存不足。原因是每次收到数据都用String拼接，产生了大量临时对象。
优化方法：尽量用字符数组代替String，用snprintf格式化数据，避免频繁的动态内存分配。比如：
char buffer[64]; snprintf(buffer, sizeof(buffer), "Temp: %.1f, Humi: %.1f", temp, humi); client.println(buffer);这样就不会产生String对象，内存占用稳定。另外，client.readStringUntil()也会创建String对象，如果数据量大，建议用client.read()逐字节读取，自己拼接到字符数组里。
还有一个技巧：定期调用ESP.getFreeHeap()查看剩余内存。如果发现内存持续下降，那肯定有地方在泄漏。我一般会在loop里每隔一分钟打印一次剩余内存，方便监控。
6. 从点对点传输延伸出的实用场景
6.1 传感器数据采集与远程显示
这是最直接的应用：一块ESP8266接DHT22温湿度传感器，开AP模式当服务端；另一块ESP8266接OLED屏幕，用STA模式连上去，每隔几秒请求一次数据并显示。
这个方案的好处是部署简单，不需要路由器，两块板子通电就能工作。我在一个温室监控的小项目里用过，服务端放在温室里，客户端放在值班室，中间隔了一百多米。因为距离太远，Wi-Fi信号衰减严重，后来在中间加了一块ESP8266做中继——中继板同时开AP和STA，一边连服务端，一边给客户端提供热点。这样信号就稳了。
6.2 双板之间的指令控制与状态回传
另一个常见场景是控制：一块ESP8266接继电器控制电机，另一块接按钮和指示灯。按下按钮，客户端发送“ON”指令，服务端收到后打开继电器，并回复“OK”。客户端收到“OK”后点亮指示灯。
这个场景里，指令的可靠性很重要，所以用TCP。而且指令很短，通常就几个字节，TCP的开销完全可以接受。我建议在协议里加一个简单的校验，比如指令后面跟一个校验和，防止误触发。
6.3 多设备组网的可行性边界
ESP8266能不能做多对多组网？理论上可以，但实际限制很多。一个AP最多支持5个左右的STA连接，而且随着连接数增加，每个连接的带宽和稳定性都会下降。
如果确实需要多设备组网，我的建议是：用一个ESP8266做中心节点（AP+STA），其他ESP8266作为终端节点（STA）。中心节点负责转发数据。但要注意，ESP8266的处理能力有限，转发延迟会比较大。如果设备超过5个，建议换用ESP32或者专门的Wi-Fi模块。
另外，ESP8266的AP模式不支持802.11n的某些高级特性，实际吞吐量大概在2到3Mbps左右。对于传感器数据这种小数据量完全够用，但如果要传音频或者图像，就力不从心了。
6.4 低功耗场景下的传输策略调整
如果设备用电池供电，功耗就是关键。ESP8266在持续工作时的电流大约70mA，深度睡眠时只有20uA左右。所以低功耗场景下，应该让设备大部分时间处于睡眠状态，定时唤醒发送数据。
具体做法：客户端每隔5分钟唤醒一次，连上服务端，发送数据，然后立刻进入深度睡眠。服务端可以一直开着，或者也做成定时唤醒。但服务端如果也睡眠，客户端就连不上了，所以通常服务端保持常开，客户端做低功耗。
实测下来，用2000mAh的电池，客户端每5分钟发一次数据，可以连续工作20天左右。如果改成每10分钟发一次，能撑一个多月。这个续航对于很多户外场景已经够用了。
注意：深度睡眠会重置ESP8266的所有状态，包括Wi-Fi连接。所以每次唤醒都需要重新连Wi-Fi、重新连服务端。这个过程大约需要2到3秒，会增加一些功耗，但总体还是比一直开着省电得多。
7. 代码之外的调试心得与长期运行建议
调试ESP8266的无线传输，串口打印是最重要的工具。我习惯在关键节点都加打印：Wi-Fi连接状态、IP地址、连接建立、数据收发、错误信息。这样一旦出问题，看串口输出就能快速定位。
另外，电源质量对Wi-Fi稳定性影响很大。我用过一些便宜的USB线，供电不足导致ESP8266频繁重启。后来换了一根粗一点的线，问题就消失了。所以如果你遇到莫名其妙的崩溃，先检查电源。
长期运行的话，建议加一个看门狗。ESP8266内置了硬件看门狗，但软件看门狗更灵活。我通常会在loop里定期调用ESP.wdtFeed()，如果某个任务卡住了，看门狗就会重启设备。这样即使出现死循环，设备也能自动恢复。
最后，固件更新是个麻烦事。如果设备装在不好拆的地方，每次改代码都要拆下来插USB，很痛苦。后来我加了一个OTA功能，通过Wi-Fi远程更新固件。虽然OTA会占用一些内存，但省去了拆装的麻烦，非常值得。
