1. 从一次400 Bad Request说起GET和POST真的不能随手换大概一个月前我在调一块ESP32的联网上报逻辑。板子连接WiFi正常MicroPython固件也跑起来了数据明明采集到了结果服务器端一连三天都返回400 Bad Request。我反复检查代码格式、缩进、API地址都对得上最后才发现问题很尴尬——我习惯用GET请求去提交传感器数据把数据全拼在了URL后面而服务端接口接收的是POST请求。这个错误特别典型尤其是刚从PC端Python转过来玩MicroPython的人特别容易在这上面栽跟头。因为MicroPython里的HTTP请求库和PC上的requests库长得非常像你很容易下意识地在ESP32上沿用过去的习惯。但ESP32的内存、网络栈和处理能力都有限HTTP请求写得不规范不仅拿不到数据还经常把设备搞重启。这篇内容就围绕ESP32上用MicroPython发HTTP GET和POST请求这件事把两类请求的本质区别、实际代码写法、以及我在真实项目里踩过的坑全部梳理一遍。无论你是刚拿到一块ESP32准备做小项目还是已经跑通基础、想搞清楚请求细节这篇文章都值得你收藏着慢慢对照。我默认你已经装好了MicroPython固件并且会用Thonny或者esptool.py往板子里刷代码。如果没有先去把固件烧录这一步搞定再回来看下面所有示例都建立在固件可用、串口能连上的基础上。2. 本质拆解GET与POST的差异不只是传参方式不同很多入门教程会把GET和POST的区别简单概括成GET把参数放在URL里POST把参数放在请求体里。这话糊弄新手可以真正做设备对接时你会因为这种粗浅理解吃大亏。2.1 HTTP请求到底长什么样任何一种HTTP请求本质上都是一个结构化的文本消息包含三个部分请求行、请求头、请求体。比如一个典型的GET请求在网络上传输的内容大致是这样的GET /api/temperature?device_idesp32_01temp26.5 HTTP/1.1 Host: 192.168.1.100:8080 User-Agent: MicroPython Accept: text/plain请求行里首先是方法名GET然后是资源路径和查询参数。POST请求的区别在于它不是把数据放在请求行的问号后面而是放在第四部分——请求体里POST /api/temperature HTTP/1.1 Host: 192.168.1.100:8080 User-Agent: MicroPython Content-Type: application/json Content-Length: 52 {device_id:esp32_01,temp:26.5}看到区别了吧POST的请求头里多了一个Content-Type和Content-Length前者告诉服务器正文用什么格式编码后者告诉服务器正文有多长。这两个字段是POST的灵魂少一个服务器都有可能解析失败。2.2 为什么设备端更倾向用POST上报数据我见过一些人用GET上报传感器数据把所有参数硬拼在URL里。短期自测没问题但只要数据量上来问题立刻暴露URL长度有上限不同服务器和网关的限制不一样有的是2048字节有的是8192字节。采集频率高、字段多的时候超长URL会被服务器直接截断。查询参数会被网关、路由、代理服务器记录在访问日志里敏感数据全部裸奔。虽然物联网设备数据多数不敏感但设计习惯还是要往严谨方向靠。有些老旧网关对URL中的特殊字符处理有bug比如、、空格一旦编码不当就报错排查成本极高。POST把数据放在请求体里长度限制宽松得多格式也更自由——JSON、表单、纯文本都行。而且Content-Type可以明确告知服务器如何处理正文双方配合起来干净利落。2.3 判断该用GET还是POST的实用标准我的个人经验是设备端接口按以下标准判断场景推荐方法原因查询设备状态、读取配置、获取服务器时间GET幂等操作不改变服务器数据可以安全重复请求上报传感器数据POST数据量大、结构化、会写入服务器数据库发送控制指令开灯、关阀POST非幂等操作服务器必须逐次处理结合查询条件获取列表GET参数简单URL可控记住一个判断口诀GET用来取数据POST用来交数据。设备端99%的上报场景都属于后者所以如果你做的事情是采集上报默认选POST不会错。3. 环境准备固件选择、WiFi连接与urequests安装3.1 固件选择的一个建议ESP32的MicroPython固件版本在官方下载页上就能找到选带SPIRAM后缀的版本通常更稳妥——如果你用的是带外部PSRAM的模组这类固件能用到更多内存。我手头的板子是某开发板4MB Flash、无外置RAM用的是通用版固件跑HTTP请求也完全够用只是大JSON响应处理时要小心点后面会讲到。MicroPython的HTTP请求库叫urequests它是对PC端requests库的精简移植。大多数情况下固件里已经内置了不需要单独安装。如果你执行import urequests时提示找不到模块可以通过包管理器安装import upip upip.install(micropython-urequests)不过前提是设备得联网。这里有个鸡生蛋的问题——你得先配好WiFi才能装库。所以我的建议是优先检查固件版本官方最新固件基本上都自带urequests没有的话再考虑烧录一个更新的固件版本而不是先联网装包。3.2 WiFi连接这一步不稳定后面全是白忙HTTP请求的前提是网络通畅。很多人在代码里直接写死WiFi连接逻辑调试时能连上一断电重启就连不上原因多半是连接函数没有等待机制就急着去发请求。我这里提供一个经过验证的稳定连接函数import network import time def connect_wifi(ssid, password, timeout15): wlan network.WLAN(network.STA_IF) wlan.active(True) if not wlan.isconnected(): print(正在连接 WiFi...) wlan.connect(ssid, password) start time.time() while not wlan.isconnected() and (time.time() - start) timeout: time.sleep(0.5) if wlan.isconnected(): print(WiFi 已连接:, wlan.ifconfig()) return True else: print(WiFi 连接失败) return False关键点在于连接到一半的时候不要立刻去发HTTP请求必须确认isconnected()返回True后再继续。我遇到过一种奇怪现象WiFi刚显示连接成功但DNS还没就绪这个时候立刻去请求域名会直接抛异常。稳妥做法是连接成功后加一个1~2秒的延迟。3.3 为什么MicroPython里用urequests而不是标准requests标准requests库功能强大但体积也大依赖一堆底层模块在ESP32这种资源受限的设备上根本跑不起来。urequests砍掉了大量PC端需要的功能只保留最核心的GET、POST、PUT等方法和基本响应对象源码只有几百行非常适合单片机场景。它和requests的差异主要体现在三方面响应对象不包含完整文本缓存流式读取避免一次性占用大量内存不支持Session会话保持每次请求都是独立的超时控制必须显式传入默认值偏长理解了这三点你在写代码时就会本能地注意内存和超时问题而不是像在PC上那样随心所欲。4. GET请求实战查询服务器数据与参数拼接细节4.1 最简GET请求代码先从最基础的情况开始查询一个服务器接口拿到返回数据。import urequests response urequests.get(http://192.168.1.100:8080/api/status) print(response.status_code) print(response.text) response.close()注意最后那行response.close()在MicroPython里特别重要。ESP32的内存只有几百KBHTTP响应对象不手动关闭内存会被一点点吃掉。请求频率高了之后设备会越跑越慢最后直接崩掉重启。4.2 如何传递查询参数GET请求的参数拼接方式单独拿出来讲是有原因的——太多人在这一步犯错。正确写法import urequests import json params device_idesp32_01typetemp url http://192.168.1.100:8080/api/query? params response urequests.get(url)错误写法最常见的一种# 错误示例 url http://192.168.1.100:8080/api/query?device_idesp32_01 url typetemp # 这样拼其实也能用但容易把已有的 ? 和 弄混拼接时必须清楚一个规则第一个参数前面用?后面的参数用连接。如果你在代码里动态拼接参数建议统一用一个函数处理def build_url(base, params_dict): if not params_dict: return base query .join([f{k}{v} for k, v in params_dict.items()]) return base ? query url build_url(http://192.168.1.100:8080/api/query, {device_id: esp32_01, type: temp})当参数值里包含空格、中文、特殊符号时需要URL编码。MicroPython的urllib.parse.quote可以做这件事from urllib.parse import quote value quote(温度传感器 01) print(value) # 输出 %E6%B8%A9%E5%BA%A6%E4%BC%A0%E6%84%9F%E5%99%A8%20014.3 响应数据的解析方式text、json与原始内容urequests的响应对象提供了三种读取方式response.text以字符串形式返回响应内容response.json()自动解析JSON并返回Python字典/列表response.content以字节形式返回原始响应内容对于获取服务器时间、读取远程配置这类JSON接口直接调用response.json()最方便response urequests.get(http://192.168.1.100:8080/api/time) if response.status_code 200: data response.json() print(服务器时间:, data.get(time)) else: print(请求失败:, response.status_code) response.close()注意不要每次都调用response.text后再用json.loads()解析这样会多一次转换操作浪费内存和时间。直接调用.json()内部已经完成解析了。4.4 GET请求的超时控制不带超时参数的请求在最坏情况下会让设备卡住几十秒甚至更久因为底层socket的默认超时时间很长。在设备端这种场景里超过5秒没响应基本就可以判定网络异常了没必要死等。try: response urequests.get(url, timeout3) except OSError as e: print(请求超时或网络异常:, e)把超时设置为3秒是个比较合理的折中值——WiFi本地网络延迟低3秒足够如果走4G模块或远距离链路可以放宽到5秒。核心原则是超时必须存在而且必须触发你的重试或降级逻辑不能让主程序卡死在等待上。5. POST请求实战传感器数据上报的完整代码5.1 POST与GET代码的最大差异相比GETPOST请求多了一个关键步骤构造请求体payload并且必须设置Content-Type告诉服务器正文格式。MicroPython的urequests里POST请求的基本形式只有一行代码urequests.post(url, datapayload, headersheaders)但payload和headers怎么构造里面学问很大。5.2 JSON格式的上报代码推荐服务端接口十有八九是接收JSON格式的数据因为JSON可读性好、跨语言支持完善。以下是完整示例import urequests import json import network # 采集的温度和湿度数据模拟值 def collect_data(): import random return { device_id: esp32_01, temperature: round(random.uniform(20.0, 30.0), 2), humidity: round(random.uniform(40.0, 70.0), 2) } def post_temperature(payload): url http://192.168.1.100:8080/api/temperature headers {Content-Type: application/json} try: response urequests.post(url, jsonpayload, headersheaders, timeout5) if response.status_code 200: print(上报成功:, response.text) else: print(上报失败, HTTP状态码:, response.status_code) response.close() except OSError as e: print(网络异常:, e) # 主程序 payload collect_data() post_temperature(payload)看到urequests.post(url, jsonpayload, ...)这行了吗json参数是urequests特意保留的便捷写法它内部会自动把Python字典序列化成JSON字符串并自动设置Content-Type: application/json。如果你手动传datajson.dumps(payload)就必须自己加headers否则服务器不知道你发的是JSON还是普通表单很有可能解析失败。5.3 表单格式的上报代码有些老旧接口或测试环境只支持application/x-www-form-urlencoded格式这时需要这样写import urequests payload device_idesp32_01temperature26.5humidity58.3 headers {Content-Type: application/x-www-form-urlencoded} response urequests.post(url, datapayload, headersheaders, timeout5)注意表单格式下的data参数是字符串形式多个字段直接用连接和GET查询参数的拼接方法一模一样。这其实说明了HTTP的哲学URL查询参数和表单提交本质是一样的编码风格位置不同而已。5.4 自定义请求头带上鉴权Token和设备标识真实项目里服务器往往需要识别设备身份。一个常见的做法是在请求头里加Authorization字段import urequests token abcdef1234567890 headers { Content-Type: application/json, Authorization: Bearer token, X-Device-Id: esp32_01 } payload {temperature: 26.5, humidity: 58.3} response urequests.post(http://192.168.1.100:8080/api/temperature, jsonpayload, headersheaders, timeout5)自定义请求头以X-开头的字段是行业惯例可以帮助服务器做设备管理和日志追踪。这里也提醒一下有些开放平台要求Token放在URL参数里而不是请求头里具体要看目标平台的接入文档不要想当然。5.5 上报失败后的重试策略物联网设备网络不稳定是常态断电、断网、路由器重启都可能导致上报失败。只发一次请求就放弃数据就会丢失。我参考了某云平台设备接入SDK的思路设计了一个简单但可靠的重试机制import time import urequests MAX_RETRY 3 def post_with_retry(url, payload, headers, max_retryMAX_RETRY): for attempt in range(1, max_retry 1): try: response urequests.post(url, jsonpayload, headersheaders, timeout5) if response.status_code 200: response.close() return True else: print(f第{attempt}次上报失败, 状态码: {response.status_code}) response.close() except OSError as e: print(f第{attempt}次网络异常: {e}) time.sleep(2 * attempt) # 退避等待2秒、4秒、6秒 return False注意重试间隔我用的是指数退避策略——每次失败后等待时间翻倍。这样不会在服务器短暂故障时造成请求风暴。6. 我在实际部署中踩过的坑内存、编码与时间同步6.1 内存不足导致设备反复重启这是ESP32跑HTTP请求最经典的问题。我早期写过一个上报程序每10秒发一次POST请求跑大概一个小时后设备自动重启。排查到最后发现是内存泄漏——每次请求的响应对象没有及时关闭加上响应数据解析时产生的临时对象没有被垃圾回收堆积到最后系统崩溃。给出三条具体建议每次请求后立刻调用response.close()请求结束后加上gc.collect()手动触发垃圾回收不要一次性请求大量数据比如一次拉取1000条记录在ESP32上几乎必死无疑import gc import urequests # 在每个请求周期结束时执行 response.close() gc.collect()6.2 响应内容编码问题的坑服务器返回的响应内容如果包含中文字符直接用response.text打印时偶尔会出现乱码。原因在于响应头里的charset字段urequests在解析时可能会猜测错误。解决办法有两种。一是手动解码data_bytes response.content text data_bytes.decode(utf-8)二是让服务器端尽量返回ASCII安全的内容格式比如纯英文状态码、数字、JSON字段名用英文。对于设备端来说这本身就是更高效的做法——传输字节更少解析开销更低。6.3 HTTPS请求与时间同步问题用HTTPS访问服务器时ESP32需要验证证书。MicroPython固件默认打包了一部分根证书但服务器的HTTPS证书有效期、设备系统时间都会影响验证结果。ESP32在没有外部RTC电池的情况下断电后系统时间会重置到固件编译时间。如果设备系统时间跑到证书有效期之外HTTPS握手就会失败。解决办法是开机后先通过NTP同步时间import ntptime import time # 先连上WiFi ntptime.settime() print(当前时间:, time.localtime())然后再发起HTTPS请求就没问题了。当然如果你的设备只访问局域网HTTP接口这一步可以跳过。6.4 服务器地址不要写死在代码里我把服务器IP写死在代码里吃过大亏——家里路由器DHCP重新分配了IP设备全连不上调试时才想起代码里有硬编码地址。后来的做法是把服务器地址放在config.py单独管理或者在设备启动时通过DNS解析域名而不是直接写IPimport socket addr_info socket.getaddrinfo(myiot.example.com, 443)[0][-1] print(解析到的服务器地址:, addr_info)这样设备端只需要记住域名服务器IP怎么变都不影响。6.5 设备端请求频率控制很多平台会限制设备的上报频率比如1秒内最多请求10次。ESP32本身没问题但网络环境、服务器容量、代码逻辑都可能触发限制。我建议在上报循环里加一个最小间隔判断import time last_post_time 0 MIN_INTERVAL 3 # 每次上报间隔至少3秒 while True: now time.time() if now - last_post_time MIN_INTERVAL: post_temperature(collect_data()) last_post_time now time.sleep(0.5)这比单纯的time.sleep(3)更可靠——当你的采集逻辑耗时较长时固定sleep会导致实际间隔变大用时间戳差值控制能让节奏更精准。7. 进阶玩法把GET和POST组合起来实现完整设备逻辑很多项目的真实需求是开机先GET获取配置然后循环POST上报数据偶尔GET检查服务器下发的指令。把前面的内容串起来就是一个完整的物联设备逻辑框架。import network import urequests import json import time import gc BASE_URL http://192.168.1.100:8080/api class IoTDevice: def __init__(self, device_id): self.device_id device_id self.config {} def fetch_config(self): url BASE_URL /config?device_id self.device_id try: response urequests.get(url, timeout3) if response.status_code 200: self.config response.json() print(获取配置成功:, self.config) response.close() except OSError as e: print(获取配置失败:, e) def report_data(self, data): url BASE_URL /data headers {Content-Type: application/json} data[device_id] self.device_id try: response urequests.post(url, jsondata, headersheaders, timeout5) if response.status_code 200: print(数据上报成功) else: print(上报失败:, response.status_code) response.close() except OSError as e: print(上报异常:, e) gc.collect() device IoTDevice(esp32_01) device.fetch_config() while True: data collect_data() # 模拟采集 device.report_data(data) time.sleep(10)这个类封装的好处是设备标识、服务器地址、请求逻辑都集中管理后续加传感器、换服务器地址只要改一个地方就行。我后来把多个项目里的上报代码都统一成这样调试效率明显提升。8. 几个值得记住的调试技巧串口打印配合日志分级是最常用的调试手段。但要注意print在MicroPython里会阻塞程序执行尤其是打印大量数据时。高频打印会影响你的上报节奏生产环境代码建议用条件编译或日志级别来控制。用response.text打印响应内容时如果内容特别长先打印长度而不是内容print(响应长度:, len(response.text)) print(响应前200字:, response.text[:200])这样既能看到关键信息又不会因为打印太多内容导致内存堆积。另一个实用技巧是在ESP32上调试HTTP请求先把目标服务器换成局域网内的测试服务器比如PC上运行一个Flask服务快速验证请求格式是否正确。等POST请求返回200了再切换到云平台或生产服务器排查问题时能省掉大量时间。最后再分享一个小习惯每次修改完代码先软复位执行一遍确认请求正常后再跑完整的定时循环。不要急着写几百行一次性跑完分段验证能让你在半小时内定位到绝大多数问题。 
长河君 · 2026/10/16 5:33:59 · 阅读 1.2k ESP32 MicroPython HTTP实战：GET与POST请求详解及避坑指南
1. 从一次400 Bad Request说起GET和POST真的不能随手换大概一个月前我在调一块ESP32的联网上报逻辑。板子连接WiFi正常MicroPython固件也跑起来了数据明明采集到了结果服务器端一连三天都返回400 Bad Request。我反复检查代码格式、缩进、API地址都对得上最后才发现问题很尴尬——我习惯用GET请求去提交传感器数据把数据全拼在了URL后面而服务端接口接收的是POST请求。这个错误特别典型尤其是刚从PC端Python转过来玩MicroPython的人特别容易在这上面栽跟头。因为MicroPython里的HTTP请求库和PC上的requests库长得非常像你很容易下意识地在ESP32上沿用过去的习惯。但ESP32的内存、网络栈和处理能力都有限HTTP请求写得不规范不仅拿不到数据还经常把设备搞重启。这篇内容就围绕ESP32上用MicroPython发HTTP GET和POST请求这件事把两类请求的本质区别、实际代码写法、以及我在真实项目里踩过的坑全部梳理一遍。无论你是刚拿到一块ESP32准备做小项目还是已经跑通基础、想搞清楚请求细节这篇文章都值得你收藏着慢慢对照。我默认你已经装好了MicroPython固件并且会用Thonny或者esptool.py往板子里刷代码。如果没有先去把固件烧录这一步搞定再回来看下面所有示例都建立在固件可用、串口能连上的基础上。2. 本质拆解GET与POST的差异不只是传参方式不同很多入门教程会把GET和POST的区别简单概括成GET把参数放在URL里POST把参数放在请求体里。这话糊弄新手可以真正做设备对接时你会因为这种粗浅理解吃大亏。2.1 HTTP请求到底长什么样任何一种HTTP请求本质上都是一个结构化的文本消息包含三个部分请求行、请求头、请求体。比如一个典型的GET请求在网络上传输的内容大致是这样的GET /api/temperature?device_idesp32_01temp26.5 HTTP/1.1 Host: 192.168.1.100:8080 User-Agent: MicroPython Accept: text/plain请求行里首先是方法名GET然后是资源路径和查询参数。POST请求的区别在于它不是把数据放在请求行的问号后面而是放在第四部分——请求体里POST /api/temperature HTTP/1.1 Host: 192.168.1.100:8080 User-Agent: MicroPython Content-Type: application/json Content-Length: 52 {device_id:esp32_01,temp:26.5}看到区别了吧POST的请求头里多了一个Content-Type和Content-Length前者告诉服务器正文用什么格式编码后者告诉服务器正文有多长。这两个字段是POST的灵魂少一个服务器都有可能解析失败。2.2 为什么设备端更倾向用POST上报数据我见过一些人用GET上报传感器数据把所有参数硬拼在URL里。短期自测没问题但只要数据量上来问题立刻暴露URL长度有上限不同服务器和网关的限制不一样有的是2048字节有的是8192字节。采集频率高、字段多的时候超长URL会被服务器直接截断。查询参数会被网关、路由、代理服务器记录在访问日志里敏感数据全部裸奔。虽然物联网设备数据多数不敏感但设计习惯还是要往严谨方向靠。有些老旧网关对URL中的特殊字符处理有bug比如、、空格一旦编码不当就报错排查成本极高。POST把数据放在请求体里长度限制宽松得多格式也更自由——JSON、表单、纯文本都行。而且Content-Type可以明确告知服务器如何处理正文双方配合起来干净利落。2.3 判断该用GET还是POST的实用标准我的个人经验是设备端接口按以下标准判断场景推荐方法原因查询设备状态、读取配置、获取服务器时间GET幂等操作不改变服务器数据可以安全重复请求上报传感器数据POST数据量大、结构化、会写入服务器数据库发送控制指令开灯、关阀POST非幂等操作服务器必须逐次处理结合查询条件获取列表GET参数简单URL可控记住一个判断口诀GET用来取数据POST用来交数据。设备端99%的上报场景都属于后者所以如果你做的事情是采集上报默认选POST不会错。3. 环境准备固件选择、WiFi连接与urequests安装3.1 固件选择的一个建议ESP32的MicroPython固件版本在官方下载页上就能找到选带SPIRAM后缀的版本通常更稳妥——如果你用的是带外部PSRAM的模组这类固件能用到更多内存。我手头的板子是某开发板4MB Flash、无外置RAM用的是通用版固件跑HTTP请求也完全够用只是大JSON响应处理时要小心点后面会讲到。MicroPython的HTTP请求库叫urequests它是对PC端requests库的精简移植。大多数情况下固件里已经内置了不需要单独安装。如果你执行import urequests时提示找不到模块可以通过包管理器安装import upip upip.install(micropython-urequests)不过前提是设备得联网。这里有个鸡生蛋的问题——你得先配好WiFi才能装库。所以我的建议是优先检查固件版本官方最新固件基本上都自带urequests没有的话再考虑烧录一个更新的固件版本而不是先联网装包。3.2 WiFi连接这一步不稳定后面全是白忙HTTP请求的前提是网络通畅。很多人在代码里直接写死WiFi连接逻辑调试时能连上一断电重启就连不上原因多半是连接函数没有等待机制就急着去发请求。我这里提供一个经过验证的稳定连接函数import network import time def connect_wifi(ssid, password, timeout15): wlan network.WLAN(network.STA_IF) wlan.active(True) if not wlan.isconnected(): print(正在连接 WiFi...) wlan.connect(ssid, password) start time.time() while not wlan.isconnected() and (time.time() - start) timeout: time.sleep(0.5) if wlan.isconnected(): print(WiFi 已连接:, wlan.ifconfig()) return True else: print(WiFi 连接失败) return False关键点在于连接到一半的时候不要立刻去发HTTP请求必须确认isconnected()返回True后再继续。我遇到过一种奇怪现象WiFi刚显示连接成功但DNS还没就绪这个时候立刻去请求域名会直接抛异常。稳妥做法是连接成功后加一个1~2秒的延迟。3.3 为什么MicroPython里用urequests而不是标准requests标准requests库功能强大但体积也大依赖一堆底层模块在ESP32这种资源受限的设备上根本跑不起来。urequests砍掉了大量PC端需要的功能只保留最核心的GET、POST、PUT等方法和基本响应对象源码只有几百行非常适合单片机场景。它和requests的差异主要体现在三方面响应对象不包含完整文本缓存流式读取避免一次性占用大量内存不支持Session会话保持每次请求都是独立的超时控制必须显式传入默认值偏长理解了这三点你在写代码时就会本能地注意内存和超时问题而不是像在PC上那样随心所欲。4. GET请求实战查询服务器数据与参数拼接细节4.1 最简GET请求代码先从最基础的情况开始查询一个服务器接口拿到返回数据。import urequests response urequests.get(http://192.168.1.100:8080/api/status) print(response.status_code) print(response.text) response.close()注意最后那行response.close()在MicroPython里特别重要。ESP32的内存只有几百KBHTTP响应对象不手动关闭内存会被一点点吃掉。请求频率高了之后设备会越跑越慢最后直接崩掉重启。4.2 如何传递查询参数GET请求的参数拼接方式单独拿出来讲是有原因的——太多人在这一步犯错。正确写法import urequests import json params device_idesp32_01typetemp url http://192.168.1.100:8080/api/query? params response urequests.get(url)错误写法最常见的一种# 错误示例 url http://192.168.1.100:8080/api/query?device_idesp32_01 url typetemp # 这样拼其实也能用但容易把已有的 ? 和 弄混拼接时必须清楚一个规则第一个参数前面用?后面的参数用连接。如果你在代码里动态拼接参数建议统一用一个函数处理def build_url(base, params_dict): if not params_dict: return base query .join([f{k}{v} for k, v in params_dict.items()]) return base ? query url build_url(http://192.168.1.100:8080/api/query, {device_id: esp32_01, type: temp})当参数值里包含空格、中文、特殊符号时需要URL编码。MicroPython的urllib.parse.quote可以做这件事from urllib.parse import quote value quote(温度传感器 01) print(value) # 输出 %E6%B8%A9%E5%BA%A6%E4%BC%A0%E6%84%9F%E5%99%A8%20014.3 响应数据的解析方式text、json与原始内容urequests的响应对象提供了三种读取方式response.text以字符串形式返回响应内容response.json()自动解析JSON并返回Python字典/列表response.content以字节形式返回原始响应内容对于获取服务器时间、读取远程配置这类JSON接口直接调用response.json()最方便response urequests.get(http://192.168.1.100:8080/api/time) if response.status_code 200: data response.json() print(服务器时间:, data.get(time)) else: print(请求失败:, response.status_code) response.close()注意不要每次都调用response.text后再用json.loads()解析这样会多一次转换操作浪费内存和时间。直接调用.json()内部已经完成解析了。4.4 GET请求的超时控制不带超时参数的请求在最坏情况下会让设备卡住几十秒甚至更久因为底层socket的默认超时时间很长。在设备端这种场景里超过5秒没响应基本就可以判定网络异常了没必要死等。try: response urequests.get(url, timeout3) except OSError as e: print(请求超时或网络异常:, e)把超时设置为3秒是个比较合理的折中值——WiFi本地网络延迟低3秒足够如果走4G模块或远距离链路可以放宽到5秒。核心原则是超时必须存在而且必须触发你的重试或降级逻辑不能让主程序卡死在等待上。5. POST请求实战传感器数据上报的完整代码5.1 POST与GET代码的最大差异相比GETPOST请求多了一个关键步骤构造请求体payload并且必须设置Content-Type告诉服务器正文格式。MicroPython的urequests里POST请求的基本形式只有一行代码urequests.post(url, datapayload, headersheaders)但payload和headers怎么构造里面学问很大。5.2 JSON格式的上报代码推荐服务端接口十有八九是接收JSON格式的数据因为JSON可读性好、跨语言支持完善。以下是完整示例import urequests import json import network # 采集的温度和湿度数据模拟值 def collect_data(): import random return { device_id: esp32_01, temperature: round(random.uniform(20.0, 30.0), 2), humidity: round(random.uniform(40.0, 70.0), 2) } def post_temperature(payload): url http://192.168.1.100:8080/api/temperature headers {Content-Type: application/json} try: response urequests.post(url, jsonpayload, headersheaders, timeout5) if response.status_code 200: print(上报成功:, response.text) else: print(上报失败, HTTP状态码:, response.status_code) response.close() except OSError as e: print(网络异常:, e) # 主程序 payload collect_data() post_temperature(payload)看到urequests.post(url, jsonpayload, ...)这行了吗json参数是urequests特意保留的便捷写法它内部会自动把Python字典序列化成JSON字符串并自动设置Content-Type: application/json。如果你手动传datajson.dumps(payload)就必须自己加headers否则服务器不知道你发的是JSON还是普通表单很有可能解析失败。5.3 表单格式的上报代码有些老旧接口或测试环境只支持application/x-www-form-urlencoded格式这时需要这样写import urequests payload device_idesp32_01temperature26.5humidity58.3 headers {Content-Type: application/x-www-form-urlencoded} response urequests.post(url, datapayload, headersheaders, timeout5)注意表单格式下的data参数是字符串形式多个字段直接用连接和GET查询参数的拼接方法一模一样。这其实说明了HTTP的哲学URL查询参数和表单提交本质是一样的编码风格位置不同而已。5.4 自定义请求头带上鉴权Token和设备标识真实项目里服务器往往需要识别设备身份。一个常见的做法是在请求头里加Authorization字段import urequests token abcdef1234567890 headers { Content-Type: application/json, Authorization: Bearer token, X-Device-Id: esp32_01 } payload {temperature: 26.5, humidity: 58.3} response urequests.post(http://192.168.1.100:8080/api/temperature, jsonpayload, headersheaders, timeout5)自定义请求头以X-开头的字段是行业惯例可以帮助服务器做设备管理和日志追踪。这里也提醒一下有些开放平台要求Token放在URL参数里而不是请求头里具体要看目标平台的接入文档不要想当然。5.5 上报失败后的重试策略物联网设备网络不稳定是常态断电、断网、路由器重启都可能导致上报失败。只发一次请求就放弃数据就会丢失。我参考了某云平台设备接入SDK的思路设计了一个简单但可靠的重试机制import time import urequests MAX_RETRY 3 def post_with_retry(url, payload, headers, max_retryMAX_RETRY): for attempt in range(1, max_retry 1): try: response urequests.post(url, jsonpayload, headersheaders, timeout5) if response.status_code 200: response.close() return True else: print(f第{attempt}次上报失败, 状态码: {response.status_code}) response.close() except OSError as e: print(f第{attempt}次网络异常: {e}) time.sleep(2 * attempt) # 退避等待2秒、4秒、6秒 return False注意重试间隔我用的是指数退避策略——每次失败后等待时间翻倍。这样不会在服务器短暂故障时造成请求风暴。6. 我在实际部署中踩过的坑内存、编码与时间同步6.1 内存不足导致设备反复重启这是ESP32跑HTTP请求最经典的问题。我早期写过一个上报程序每10秒发一次POST请求跑大概一个小时后设备自动重启。排查到最后发现是内存泄漏——每次请求的响应对象没有及时关闭加上响应数据解析时产生的临时对象没有被垃圾回收堆积到最后系统崩溃。给出三条具体建议每次请求后立刻调用response.close()请求结束后加上gc.collect()手动触发垃圾回收不要一次性请求大量数据比如一次拉取1000条记录在ESP32上几乎必死无疑import gc import urequests # 在每个请求周期结束时执行 response.close() gc.collect()6.2 响应内容编码问题的坑服务器返回的响应内容如果包含中文字符直接用response.text打印时偶尔会出现乱码。原因在于响应头里的charset字段urequests在解析时可能会猜测错误。解决办法有两种。一是手动解码data_bytes response.content text data_bytes.decode(utf-8)二是让服务器端尽量返回ASCII安全的内容格式比如纯英文状态码、数字、JSON字段名用英文。对于设备端来说这本身就是更高效的做法——传输字节更少解析开销更低。6.3 HTTPS请求与时间同步问题用HTTPS访问服务器时ESP32需要验证证书。MicroPython固件默认打包了一部分根证书但服务器的HTTPS证书有效期、设备系统时间都会影响验证结果。ESP32在没有外部RTC电池的情况下断电后系统时间会重置到固件编译时间。如果设备系统时间跑到证书有效期之外HTTPS握手就会失败。解决办法是开机后先通过NTP同步时间import ntptime import time # 先连上WiFi ntptime.settime() print(当前时间:, time.localtime())然后再发起HTTPS请求就没问题了。当然如果你的设备只访问局域网HTTP接口这一步可以跳过。6.4 服务器地址不要写死在代码里我把服务器IP写死在代码里吃过大亏——家里路由器DHCP重新分配了IP设备全连不上调试时才想起代码里有硬编码地址。后来的做法是把服务器地址放在config.py单独管理或者在设备启动时通过DNS解析域名而不是直接写IPimport socket addr_info socket.getaddrinfo(myiot.example.com, 443)[0][-1] print(解析到的服务器地址:, addr_info)这样设备端只需要记住域名服务器IP怎么变都不影响。6.5 设备端请求频率控制很多平台会限制设备的上报频率比如1秒内最多请求10次。ESP32本身没问题但网络环境、服务器容量、代码逻辑都可能触发限制。我建议在上报循环里加一个最小间隔判断import time last_post_time 0 MIN_INTERVAL 3 # 每次上报间隔至少3秒 while True: now time.time() if now - last_post_time MIN_INTERVAL: post_temperature(collect_data()) last_post_time now time.sleep(0.5)这比单纯的time.sleep(3)更可靠——当你的采集逻辑耗时较长时固定sleep会导致实际间隔变大用时间戳差值控制能让节奏更精准。7. 进阶玩法把GET和POST组合起来实现完整设备逻辑很多项目的真实需求是开机先GET获取配置然后循环POST上报数据偶尔GET检查服务器下发的指令。把前面的内容串起来就是一个完整的物联设备逻辑框架。import network import urequests import json import time import gc BASE_URL http://192.168.1.100:8080/api class IoTDevice: def __init__(self, device_id): self.device_id device_id self.config {} def fetch_config(self): url BASE_URL /config?device_id self.device_id try: response urequests.get(url, timeout3) if response.status_code 200: self.config response.json() print(获取配置成功:, self.config) response.close() except OSError as e: print(获取配置失败:, e) def report_data(self, data): url BASE_URL /data headers {Content-Type: application/json} data[device_id] self.device_id try: response urequests.post(url, jsondata, headersheaders, timeout5) if response.status_code 200: print(数据上报成功) else: print(上报失败:, response.status_code) response.close() except OSError as e: print(上报异常:, e) gc.collect() device IoTDevice(esp32_01) device.fetch_config() while True: data collect_data() # 模拟采集 device.report_data(data) time.sleep(10)这个类封装的好处是设备标识、服务器地址、请求逻辑都集中管理后续加传感器、换服务器地址只要改一个地方就行。我后来把多个项目里的上报代码都统一成这样调试效率明显提升。8. 几个值得记住的调试技巧串口打印配合日志分级是最常用的调试手段。但要注意print在MicroPython里会阻塞程序执行尤其是打印大量数据时。高频打印会影响你的上报节奏生产环境代码建议用条件编译或日志级别来控制。用response.text打印响应内容时如果内容特别长先打印长度而不是内容print(响应长度:, len(response.text)) print(响应前200字:, response.text[:200])这样既能看到关键信息又不会因为打印太多内容导致内存堆积。另一个实用技巧是在ESP32上调试HTTP请求先把目标服务器换成局域网内的测试服务器比如PC上运行一个Flask服务快速验证请求格式是否正确。等POST请求返回200了再切换到云平台或生产服务器排查问题时能省掉大量时间。最后再分享一个小习惯每次修改完代码先软复位执行一遍确认请求正常后再跑完整的定时循环。不要急着写几百行一次性跑完分段验证能让你在半小时内定位到绝大多数问题。