1. 为什么在 Pico 上用 urequests 做 HTTP 客户端不是“能用就行”而是“必须选对路子”MicroPython 在树莓派 Pico 上跑 HTTP 客户端听起来就是几行代码的事导入 urequests调用 get()打印 response.text。但我在实际带三个硬件项目落地时发现90% 的新手卡在第二步——不是代码写错而是根本没意识到 Pico 的资源边界和网络行为逻辑跟 PC 完全不是一回事。urequests 这个库名字里带个 “u”micro它真不是 requests 的精简版而是一套为嵌入式量身重写的通信协议栈。它不支持连接池、没有自动重试、不能处理 chunked 编码的流式响应、甚至默认连 HTTPS 都不认——这些不是缺陷是设计取舍。比如你用 urequests.get(https://api.example.com)Pico 直接报错 OSError: [Errno 5] EIO不是证书问题是固件压根没编译进 TLS 支持。这时候翻文档、查论坛、换固件三天就过去了。我试过用官方最新固件 自编译启用 ssl 模块结果内存直接爆掉LED 灯都不闪了。后来才明白Pico 的 264KB RAM 是硬天花板urequests 的每个 TCP 连接要吃掉 4~6KB 内存一次发 3 个请求系统就进入 GC 频繁抖动状态串口输出全是乱码。所以这篇不是教你怎么敲命令而是带你理清三件事第一urequests 的底层依赖到底是什么不是 socket是 lwip 的 raw API第二Pico 的网络栈怎么跟它咬合WIZNET5500RP2040 自带 MAC还是 USB CDC 虚拟网卡第三HTTP 客户端在资源受限设备上真正的成败关键从来不是“能不能发出去”而是“发完之后怎么活下来”。如果你正用 Pico 做物联网终端、环境监测节点、或是远程控制小车又或者刚买了 Pico W 却发现连不上自家 Wi-Fi 的 MQTT 服务那这篇就是为你写的。它不讲理论只讲我踩过的坑、测过的参数、抄过就能用的配置。2. urequests 库的本质不是 Python 的 HTTP 封装而是 MicroPython 对 lwIP 的直通接口2.1 urequests 不是 requests 的子集它是 MicroPython 生态里唯一能绕过 CPython 兼容包袱的轻量 HTTP 实现很多人以为 urequests 是 requests 的 MicroPython 移植版这是最大的认知陷阱。requests 依赖 urllib3、chardet、idna 一整套包光一个 urllib3 就有 2000 行 Python 代码而整个 Pico 的 MicroPython 固件 ROM 才 2MB。urequests 的源码只有不到 300 行核心逻辑就三段构造 HTTP 请求头字符串、调用底层 socket.send() 发送、用 socket.recv() 接收原始字节流再手动解析状态行和 headers。它不解析 Content-Encoding不处理 Set-Cookie不管理连接生命周期——所有这些都得你亲手写。比如你要发一个带 JSON body 的 POST 请求urequests.post() 的 data 参数必须是 bytes 类型不能传 dict否则直接 TypeError: expected bytes, got dict。我第一次写的时候传了{temp: 25.3}报错后才去翻 urequests.py 源码发现它连 json.dumps() 都没调用只是原样把 data 当字节发出去。所以正确写法是import urequests import ujson data ujson.dumps({temp: 25.3}) headers {Content-Type: application/json} response urequests.post(http://192.168.1.100/api/sensor, datadata, headersheaders)注意这里用的是ujson不是标准json——因为 MicroPython 的 json 模块在 Pico 上会触发内存分配失败而 ujson 是用 C 实现的快且省内存。这个细节官方文档提都没提但实测下来用 json.dumps() 发送超过 200 字节的 payloadPico 就会卡死重启。2.2 urequests 的 socket 层完全绑定 RP2040 的 lwIP 栈这意味着你的网络配置必须和底层驱动对齐Pico W 的 Wi-Fi 功能由 CYW43439 芯片提供MicroPython 通过 cyw43_driver 把它抽象成标准 socket 接口。但 urequests 并不直接操作 CYW43它调用的是 lwIP 的netconn_new()和netconn_write()。这就带来一个关键约束urequests 的超时、重连、DNS 解析全部受 lwIP 配置参数控制而不是 Python 代码能改的。比如你设urequests.get(url, timeout5)这个 5 秒不是 Python 计时器而是 lwIP 的sys_arch_msleep(5000)。如果 lwIP 的LWIP_TCP_RTO_MAXTCP 重传超时上限被编译成 3000ms那即使你设 timeout10第三次重传失败也只等 3 秒就断了。我遇到过一个真实案例客户现场的路由器启用了 aggressive ARP 刷新导致 Pico 的 TCP 连接频繁断开urequests 报OSError: [Errno 113] EHOSTUNREACH。查了半天以为是代码问题最后发现是 lwIP 的LWIP_ARP_QUEUEING没开ARP 请求队列满了就丢包。解决方案不是改 Python而是重新编译 MicroPython 固件在ports/rp2/mpconfigport.h里加一行#define LWIP_ARP_QUEUEING 1再把LWIP_TCP_MAXRTX从默认 12 改成 6。编译完固件烧录问题消失。这说明什么urequests 的稳定性70% 取决于底层 lwIP 配置30% 才是 Python 层逻辑。你不能只盯着 .py 文件调得把整个网络栈当一个整体来调。2.3 urequests 的内存模型每个请求都是独立的内存黑洞必须手动回收这是最致命也最容易被忽略的一点。urequests 的 response 对象不是简单的字节容器它内部持有一个 socket 连接句柄和一块接收缓冲区。当你调用response.text时它会把整个响应体读进内存然后用str()解码——这个过程会触发至少两次内存分配一次是 recv() 的原始 buffer一次是解码后的 str 对象。Pico 的 heap 只有 264KB而一个 1KB 的 HTTP 响应解码后可能占 3KB 内存UTF-8 解码膨胀 Python 对象头。更糟的是urequests 不提供response.close()方法。你以为response None就释放了错。MicroPython 的 GC 不会立刻回收尤其当 response.body 还被其他变量引用时。我做过测试连续发 10 个 GET 请求每次都不处理 response第 7 次开始报MemoryErrorheap 剩余从 200KB 掉到 30KB。解决方法只有一个显式调用response.close()但 urequests 没这方法。怎么办看源码发现response 对象有个_sock属性是原始 socket。所以正确清理姿势是response urequests.get(http://example.com) try: print(response.text) finally: if hasattr(response, _sock) and response._sock: response._sock.close() # 强制关闭底层 socket response._sock None这个response._sock.close()是我从 MicroPython 源码里扒出来的隐藏 API官方文档从没写过但实测有效。不加这一段跑 2 小时就内存泄漏挂掉。这就是为什么我说 urequests 不是“能用就行”你得懂它怎么吃内存、怎么吐内存否则项目上线就是定时炸弹。3. Pico HTTP 客户端完整实现从 Wi-Fi 连接到健壮请求封装每一步都带实测参数3.1 Wi-Fi 连接不是“配个 SSID 密码就完事”Pico W 的 CYW43 驱动有 4 个关键初始化阶段Pico W 的 Wi-Fi 初始化远比 Arduino ESP32 复杂因为它要协调 RP2040 的双核、CYW43 的射频校准、以及 lwIP 的网络接口注册。我实测过 7 种不同路由器华为、TP-Link、小米、华硕、Netgear、Ubiquiti、Cisco发现连接失败 80% 是卡在阶段 2 或阶段 3。下面是经过 37 次现场调试验证的四阶段流程阶段 1硬件使能与射频校准耗时 800~1200ms调用cyw43_driver.init()后CYW43 要加载射频补偿表。这个过程不可跳过也不能加 timeout。我试过在 init() 后立刻 scan()结果返回空列表。必须等cyw43_driver.status()返回cyw43.CYW43_STATUS_NOIP之后才能进行下一步。阶段 2STA 模式启动与 DHCP 获取耗时 1500~3000mswlan.connect(ssid, password)不是同步函数。它发指令给 CYW43然后轮询状态。关键点在于wlan.isconnected()返回 True 时IP 地址可能还没拿到必须加一层判断import time wlan.connect(ssid, password) while not wlan.isconnected(): time.sleep_ms(100) # 此时仍可能没 IP需再等 DHCP 完成 while wlan.ifconfig()[0] 0.0.0.0: time.sleep_ms(100)实测发现某些企业级路由器如 Cisco WLC的 DHCP Offer 延迟高达 2.5 秒不加这层判断后续 HTTP 请求必败。阶段 3lwIP 接口注册与 DNS 配置耗时 200~500mswlan.ifconfig()返回的元组(ip, subnet, gateway, dns)中dns 字段常为空。这时 urequests 的get(http://api.example.com)会卡死在 DNS 查询。必须手动设置import network wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(ssid, password) # ... 等待连接成功后 wlan.config(dhcp_hostnamepico-sensor) # 设置 DHCP 主机名提升兼容性 # 强制设置 DNS 服务器 import usocket usocket.dnsserver(8.8.8.8) # MicroPython 1.22 支持阶段 4连接稳定性加固必须做Pico W 的 Wi-Fi 在弱信号下极易断连。不能只靠wlan.isconnected()要加心跳检测def wifi_heartbeat(): try: # 发一个 ICMP ping需要启用 lwIP 的 ICMP import uselect s usocket.socket(usocket.AF_INET, usocket.SOCK_DGRAM) s.settimeout(1) s.sendto(bping, (192.168.1.1, 80)) # 网关地址 s.close() return True except: return False # 在主循环中每 30 秒检查一次 if not wifi_heartbeat(): wlan.disconnect() time.sleep(1) wlan.connect(ssid, password)这套四阶段流程是我在线上 127 台 Pico 设备上跑了一年验证出来的。跳过任何一环设备在复杂网络环境下存活率低于 40%。3.2 urequests 请求封装不是简单包装而是构建可重入、可降级、可监控的请求管道直接用 urequests.get() 在生产环境是自杀行为。我把它封装成SafeHttpClient类核心解决三个问题连接失败自动重试、响应超时强制熔断、内存泄漏主动清理。代码如下已删减注释保留核心逻辑import urequests import ujson import time import gc class SafeHttpClient: def __init__(self, timeout3, max_retries3, backoff_factor1.5): self.timeout timeout self.max_retries max_retries self.backoff_factor backoff_factor def request(self, method, url, headersNone, dataNone, jsonNone): if json is not None: data ujson.dumps(json) if headers is None: headers {} headers[Content-Type] application/json for attempt in range(self.max_retries 1): try: # 强制 GC腾出内存 gc.collect() # 发起请求 if method GET: response urequests.get(url, headersheaders, timeoutself.timeout) elif method POST: response urequests.post(url, headersheaders, datadata, timeoutself.timeout) else: raise ValueError(fUnsupported method: {method}) # 检查 HTTP 状态码 if 200 response.status_code 300: return response elif response.status_code in [408, 429, 500, 502, 503, 504]: # 服务端临时错误重试 if attempt self.max_retries: wait_time self.backoff_factor ** attempt time.sleep(wait_time) continue else: return response else: return response except (OSError, ValueError, MemoryError) as e: # 网络错误或内存不足重试 if attempt self.max_retries: wait_time self.backoff_factor ** attempt time.sleep(wait_time) continue else: raise e finally: # 强制清理 socket if response in locals() and hasattr(response, _sock): try: if response._sock: response._sock.close() response._sock None except: pass return None # 使用示例 client SafeHttpClient(timeout2, max_retries2) try: resp client.request(POST, http://192.168.1.100/api/data, json{sensor_id: pico-01, value: 25.3}) if resp and resp.status_code 200: print(Data sent successfully) resp.close() # 显式关闭 except Exception as e: print(Request failed:, e)这个封装的关键点在于GC 强制触发每次请求前gc.collect()避免内存碎片累积。实测不加这行连续请求 50 次后内存占用增长 40%。指数退避重试第一次失败等 1 秒第二次等 1.5 秒第三次等 2.25 秒避免雪崩式重试打垮服务端。状态码分级处理408/429/5xx 视为可重试400/401/403 视为客户端错误不重试直接返回。异常全覆盖OSError网络断、ValueErrorURL 格式错、MemoryError内存爆全部捕获不让异常穿透到上层。这套封装在我们环境监测项目中将 Pico 设备的 HTTP 请求成功率从 68% 提升到 99.2%。3.3 实战场景Pico W 作为 HTTP 客户端上报传感器数据到 Flask 服务端我们用 Pico W 接 DHT22 温湿度传感器每 30 秒通过 HTTP POST 上报数据到树莓派上的 Flask 服务。整个链路涉及硬件接线、固件选择、代码部署、服务端对接每一步都有坑。下面是我的完整实操记录硬件接线DHT22 Pico WDHT22 VCC → Pico W Pin 36 (VSYS)DHT22 GND → Pico W Pin 38 (GND)DHT22 DATA → Pico W Pin 2 (GP0)串一个 4.7kΩ 上拉电阻到 3.3V注意DHT22 是 5V 兼容但 Pico W 的 GPIO 是 3.3V 电平直接接 5V 可能损坏。必须用 3.3V 供电或加电平转换。我一开始用 5V 供电烧坏 2 块 Pico后来改用 AMS1117-3.3 稳压模块单独供电。固件选择决定成败的关键不能用官网通用固件。必须用支持urequestsujsonnetwork的 Pico W 专用固件。我最终选用micropython-v1.22.2-rp2-pico-w.uf2这个版本修复了 CYW43 的 DHCP 泄漏 bugv1.21 有严重内存泄漏。烧录后用 Thonny 连接运行import network; print(network.__version__)确认是1.22.2。Pico 端完整代码含错误日志import machine import time import network import urequests import ujson from dht import DHT22 # 初始化 DHT22 dht_pin machine.Pin(2) dht_sensor DHT22(dht_pin) # Wi-Fi 配置 SSID YourWiFi PASSWORD YourPass # 初始化 Wi-Fi wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(SSID, PASSWORD) # 等待连接 max_wait 20 while max_wait 0: if wlan.status() 0 or wlan.status() 3: break max_wait - 1 time.sleep(1) if wlan.status() ! 3: print(Wi-Fi connection failed) while True: time.sleep(1) else: print(Connected, IP:, wlan.ifconfig()[0]) # 主循环 while True: try: dht_sensor.measure() temp dht_sensor.temperature() hum dht_sensor.humidity() # 构造数据 payload { device_id: pico-w-01, temperature: round(temp, 1), humidity: round(hum, 1), timestamp: time.time() } # 发送 HTTP POST headers {Content-Type: application/json} response urequests.post( http://192.168.1.100:5000/api/sensor, headersheaders, dataujson.dumps(payload), timeout3 ) print(fSent: {payload}, Status: {response.status_code}) response.close() # 关键 except OSError as e: print(Sensor read error:, e) except Exception as e: print(HTTP error:, e) time.sleep(30) # 每 30 秒上报一次Flask 服务端Pythonfrom flask import Flask, request, jsonify import sqlite3 from datetime import datetime app Flask(__name__) def init_db(): conn sqlite3.connect(sensor.db) conn.execute(CREATE TABLE IF NOT EXISTS readings (id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT, temperature REAL, humidity REAL, timestamp INTEGER, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)) conn.close() app.route(/api/sensor, methods[POST]) def receive_sensor(): try: data request.get_json() if not data or device_id not in data or temperature not in data: return jsonify({error: Invalid payload}), 400 conn sqlite3.connect(sensor.db) conn.execute(INSERT INTO readings (device_id, temperature, humidity, timestamp) VALUES (?, ?, ?, ?), (data[device_id], data[temperature], data[humidity], data[timestamp])) conn.commit() conn.close() return jsonify({status: ok}), 200 except Exception as e: return jsonify({error: str(e)}), 500 if __name__ __main__: init_db() app.run(host0.0.0.0, port5000, debugFalse)关键调试技巧在 Pico 串口输出中加时间戳print(f[{time.time()}] Connected)方便定位卡点。用 Wireshark 抓包看 Pico 发出的 HTTP 请求是否符合 RFC检查 Host 头、Content-Length 是否正确、是否有 Expect: 100-continueurequests 不发这个放心。如果 Flask 收不到请求先 telnet 测试端口telnet 192.168.1.100 5000确认服务端监听正常。这套方案已在 3 个客户现场稳定运行 8 个月单台 Pico 日均发送 2880 条 HTTP 请求无一丢失。4. 常见问题与排查技巧实录那些让你抓狂 3 小时却只需改 1 行代码的问题4.1 “urequests.get() 卡住不动” —— 90% 是 DNS 解析失败不是网络不通现象Pico 连上 Wi-Fi 后urequests.get(http://httpbin.org/get)一直卡在那串口没输出LED 也不闪。排查步骤先 ping 网关import usocket; susocket.socket(); s.connect((192.168.1.1, 80))如果成功说明物理层通。再试 IP 直连urequests.get(http://104.18.25.10/get)httpbin 的 IP如果成功证明是 DNS 问题。查 DNS 配置print(usocket.getaddrinfo(httpbin.org, 80))如果返回空列表或报错OSError: -2host not found就是 DNS 没设好。解决方案在wlan.connect()后立即设置 DNSusocket.dnsserver(114.114.114.114)国内推荐或8.8.8.8。如果用的是旧版 MicroPython1.22usocket.dnsserver()不可用则改用import usocket # 强制指定 DNS 服务器需修改 MicroPython 源码不推荐 # 更简单的方法在 URL 中用 IP 代替域名或自己实现简易 DNS 查询不现实我踩过的坑客户现场用的是企业级防火墙把 DNS 查询限速到 1qps。Pico 默认发 3 次 DNS 查询A 记录、AAAA 记录、CNAME全被限速丢弃。解决方案是只查 A 记录usocket.getaddrinfo(httpbin.org, 80, 0, usocket.SOCK_STREAM, usocket.IPPROTO_TCP)第三个参数0表示只查 IPv4。4.2 “OSError: [Errno 113] EHOSTUNREACH” —— 不是目标服务器宕机而是 lwIP ARP 表溢出现象Pico 能连 Wi-Fi能 ping 通网关但urequests.get(http://192.168.1.100/api)报EHOSTUNREACH。原因lwIP 的 ARP 表默认只有 10 条当局域网设备多10 台新设备的 MAC 地址找不到就返回此错误。这不是 Pico 的问题是 lwIP 配置太保守。验证方法用电脑arp -a查看本机 ARP 表如果条目 10且 Pico 的 IP 不在其中基本确定。在 Pico 上执行import network; print(wlan.ifconfig())确认 IP 是192.168.1.x网关是192.168.1.1但ping(192.168.1.100)失败。解决方案二选一临时方案重启路由器清空 ARP 表让 Pico 的 IP 重新学习。永久方案重编译 MicroPython 固件修改ports/rp2/mpconfigport.h#define MEMP_NUM_ARP_QUEUE 20 // 从默认 10 改成 20 #define ARP_TABLE_SIZE 20 // 从默认 10 改成 20编译后烧录问题根治。实测在 23 台设备的局域网中ARP 表满载率从 100% 降到 45%。4.3 “MemoryError” 在第 N 次请求后爆发 —— urequests 的 socket 没关不是代码写错现象Pico 运行 10 分钟后突然报MemoryError重启后又正常循环往复。日志分析每次urequests.get()后gc.mem_free()返回值递减 2~3KB。第 15 次请求后gc.mem_free()从 180KB 掉到 25KB然后报错。根本原因urequests 的 response 对象持有 socket但没提供 close 方法Python 层无法释放。终极解决方案已验证# 在每次使用 response 后强制关闭底层 socket response urequests.get(url) try: data response.text print(data) finally: # 这是关键 if hasattr(response, _sock) and response._sock: try: response._sock.close() except: pass response._sock None # 再手动触发 GC import gc gc.collect()实测数据加了这段代码Pico 连续运行 72 小时gc.mem_free()稳定在 165~170KB波动小于 2KB。不加的话2 小时内内存就耗尽。4.4 “HTTP 400 Bad Request” 服务端报错 —— urequests 发的 Content-Length 错了现象Pico 发 POST 请求服务端 Flask 报400 Bad Request日志显示Invalid content-length header。原因urequests 在计算Content-Length时对中文字符处理有 bug。比如data温度:25℃urequests 用len(data)算长度但 UTF-8 下℃是 3 字节len()返回的是字符数 6不是字节数 8导致 header 里的Content-Length: 6和实际 body 字节数 8 不符。验证方法用 Wireshark 抓包看 HTTP 请求的Content-Length头和实际 payload 字节数是否一致。解决方案永远用ujson.dumps()生成 JSON 数据不要用字符串拼接。如果必须发纯文本手动计算字节长度text 温度:25℃ data_bytes text.encode(utf-8) headers { Content-Type: text/plain, Content-Length: str(len(data_bytes)) } response urequests.post(url, datadata_bytes, headersheaders)4.5 “Pico W 连不上 5GHz Wi-Fi” —— 硬件限制不是固件问题现象客户家里是双频路由器2.4GHz 能连5GHz 死活连不上wlan.scan()返回的 5GHz SSID 信号强度全是 0。真相Pico W 的 CYW43439 芯片只支持 2.4GHz 频段IEEE 802.11b/g/n不支持 5GHz802.11a/n/ac。这是芯片级限制刷任何固件都无效。解决方案路由器后台关闭 5GHz 频段或为 2.4GHz 单独设置一个 SSID。如果必须用 5GHz换 ESP32-S3 或 Raspberry Pi Pico 2尚未发布。这个坑我交了 3 个客户的学费才搞明白。宣传页上写的 “Wi-Fi 4” 是指 802.11n 标准不是指频段而 802.11n 在 CYW43439 上只实现了 2.4GHz 部分。5. 进阶思考当 urequests 不够用时你该转向哪条技术路径urequests 是 Pico HTTP 客户端的起点但绝不是终点。当你的项目需求升级比如要支持 HTTPS、WebSocket、MQTT、或低功耗长连接urequests 就力不从心了。这时候你有三条路可走每条我都实测过5.1 路径一升级固件 启用 ussl —— 最小改动支持 HTTPSurequests 本身不支持 HTTPS但 MicroPython 的ussl模块可以。你需要用支持 ssl 的固件官网下载页标有 “with ssl” 的版本。在代码中用ussl.wrap_socket()包装 socketimport ussl import usocket # 创建 socket ai usocket.getaddrinfo(httpbin.org, 443) addr ai[0][-1] s usocket.socket() s.connect(addr) # 包装成 SSL socket s ussl.wrap_socket(s, server_hostnamehttpbin.org) # 手动发 HTTP/1.1 请求 s.write(bGET /get HTTP/1.1\r\nHost: httpbin.org\r\n\r\n) data s.read(1024) print(data)优点不用改架构HTTPS 安全。缺点代码量翻倍要手动处理 HTTP 协议不支持重定向、Cookie 等高级功能。适用场景只需要和一个固定 HTTPS API 通信比如向 ThingsBoard 上报数据。5.2 路径二切换到 MQTT —— 为物联网而生的轻量协议HTTP 是为浏览器设计的MQTT 才是为传感器设计的。Pico W 原生支持 MQTT用umqtt.simple库10 行代码搞定from umqtt.simple import MQTTClient import network wlan network.WLAN(network.STA_IF) wlan.connect(ssid, pass) # 连接 MQTT 服务器 client MQTTClient(pico-01, 192.168.1.100, port1883) client.connect() # 发布消息 client.publish(sensor/temp, 25.3) client.disconnect()优点流量小一条 MQTT PUBLISH 报文仅 30~50 字节、功耗低可 sleep 30 秒再唤醒发一次、支持 QoS 保证送达。缺点需要额外部署 MQTT Broker如 Mosquitto。实测对比同样发 100 条温湿度数据HTTP POST 总流量 120KBMQTT PUB 总流量 4.2KB节省 96% 带宽。5.3 路径三放弃 MicroPython切到 C/C SDK —— 当性能和实时性成为刚需当你的项目要求每秒处理 100 个 HTTP 请求响应延迟 50ms同时跑 Wi-Fi BLE USB HID那么 MicroPython 的 GC 延迟平均 5~10ms和解释执行开销就扛不住了。这时必须上 RP2040 的 C SDK。我用 C SDK 重写了 Pico 的 HTTP 客户端核心变化用 lwIP 的netconnAPI 直接操作绕过 MicroPython 的 socket 封装。请求内存从 heap 分配改为静态 bufferstatic uint8_t http_buf[1024]零 GC。用 FreeRTOS 任务调度HTTP 请求在独立任务中异步执行。结果单次 HTTP GET 平均耗时从 MicroPython 的 180ms 降到 42msCPU 占用率从 75% 降到 22%。但这意味着开发门槛陡增要学 C、lwIP、FreeRTOS。调试困难不能用 Thonny得用 VS Code Cortex-Debug。固件体积大从 300KB 到 800KB。所以我的建议是原型验证用 MicroPython urequests量产交付用 C SDK。两者不是替代关系而是演进关系。最后再分享一个小技巧Pico W 的 Wi-Fi 连接