必须先调用uni.startWifi，否则所有WiFi API静默失败；需在用户触发同步回调中立即执行，不可异步；安卓须先申请location权限，iOS需start后立刻getWifiList；扫码URI须标准格式，connectWifi参数要严格匹配；配网需在onWifiConnected后发起TCP/UDP通信。
uni.startWifi 必须先调，否则所有 WiFi API 都静默失败
很多开发者扫完码或点“连接”按钮后直接调 uni.connectWifi，结果返回空对象或 errCode: 12004（模块未启用）。这不是 bug，是微信小程序的硬性设计：WiFi 模块默认惰性加载，不显式启动就等于没插电。
必须在用户触发动作（如扫码成功、按钮点击）的同步回调里立即执行 uni.startWifi，不能包进 setTimeout、Promise.then 或任何异步队列中。iOS 上它不报错但后续全失效；Android 上常直接 fail 且不弹权限提示——尤其当你还没申请 scope.userLocation 权限时。
- 安卓端：调
uni.startWifi前，务必先uni.authorize({ scope: 'scope.userLocation' })，否则静默失败 - iOS 端：无需提前授权，但
startWifi成功后需立刻调一次uni.getWifiList触发扫描，不能只等uni.onGetWifiList - 真机调试时，模拟器永远返回空列表，必须用真机
扫码解析出的 SSID 和密码必须符合 Wi-Fi URI 标准格式
不是所有带 “wifi” 字样的二维码都能连上。微信只认标准 Wi-Fi 配网 URI，例如：wifi:S:MyNetwork;T:WPA;P:mypass123;;。末尾两个分号缺一不可，类型 T 必须是 WEP、WPA 或 nopass，大小写敏感。
如果扫码得到的是 JSON、URL 参数或自定义字符串（比如 {"ssid":"xxx","pwd":"yyy"}），uni.connectWifi 会直接报 errCode: 12005（参数错误），而不是提示格式不对。
- 推荐用服务端生成标准 URI，前端只负责扫码 + 解析字段，不要自己拼接
- 解析时注意：URI 中的
S:后是 SSID，P:后是密码，T:后是加密类型，中间用分号分隔 - 若设备热点名含空格或特殊字符，URI 中需 URL 编码，但微信扫码 API 通常已自动解码，传参前可先
decodeURIComponent保险
uni.connectWifi 在安卓和 iOS 的行为差异极大
同一段代码，在两台手机上可能一个秒连、一个卡死。核心差异不在 JS 层，而在系统底层策略：
- 安卓端：必须加
forceNewApi: true参数，否则旧 API 在 Android 9+ 上大概率失败；连接后不会自动跳回你 App，得靠uni.onWifiConnected监听回调 - iOS 端：不支持
forceNewApi，传了会报错；连接成功后系统弹窗确认，用户点“加入”才算真正连上，此时才会触发onWifiConnected - 两者都要求：SSID 必须完全匹配（区分大小写、空格），密码不能有多余空格；若设备热点未广播 SSID（隐藏网络），
connectWifi会失败，无法强制连接
连接设备热点后，别忘了 TCP/UDP 通信配网才是最终目的
连上设备的 AP 热点（比如 ESP32_AP_XXXX）只是第一步。真正的配网逻辑是：手机连上后，通过 TCP 或 UDP 把家庭路由器的 SSID 和密码发给设备，让它自己去连外网。
这时候容易忽略两点：一是设备热点 IP 通常是固定内网地址（如 192.168.4.1），二是小程序的 uni.createTCPSocket 或 uni.createUDPSocket 必须在 onWifiConnected 回调之后再创建，否则 socket 会因网络未就绪而 connect 失败。
- UDP 发送示例结构：
{"cmdType":1,"ssid":"Home-2G","password":"12345678"}，注意 JSON 必须合法、无换行 - TCP 连接前建议加 500ms 延迟，等系统路由表刷新完成，否则
connect可能超时 - 连接失败时，优先检查设备是否仍在 AP 模式（指示灯是否快闪）、UDP 端口是否为设备默认（常见 8266/5000）
startWifi 调用时机、权限申请顺序、以及对“连接成功”的定义偏差——系统说连上了，不代表设备已收包；设备说配网成功，也不代表你 App 已收到响应。这些链路环节没有日志埋点，很容易误判故障点。 
