react 的 fiber 是内部渲染协调机制，不参与局域网设备发现；设备搜寻需由后端或系统级运行时执行网络探测，fiber 仅负责高效渲染返回的设备列表。
Fiber 不是网络发现框架，它和局域网设备搜寻完全无关。React 的 Fiber 是其内部渲染协调机制，用于调度组件更新、中断与恢复渲染任务，不处理网络通信、UDP 广播、mDNS 或任何设备发现协议。
为什么你会混淆 Fiber 和设备发现
常见误解来自关键词“Fiber”被误当作某种轻量级通信框架或嵌入式网络库。实际上：
-
Fiber仅存在于 React 运行时（浏览器或服务端 React 渲染器中），不会编译进前端产物之外的环境 - 它不暴露任何网络 API，也不依赖
fetch、WebSocket、WebRTC或原生 socket - 局域网设备搜寻必须依赖操作系统/硬件层能力：如 UDP 多播（SSDP）、DNS-SD（mDNS）、ARP 扫描、ICMP ping、或厂商私有协议（如 Mi Home 的 UDP 心跳）
真正可行的局域网设备自动搜寻方案
若你在开发一个前端界面（比如用 React 写的 IoT 控制面板），需要“发现局域网内的设备”，实际链路是：
- 前端调用后端 API（如
/api/discover） - 后端（Node.js / Python / Rust 等）执行真实网络探测（例如发送 SSDP M-SEARCH、监听 1900/udp、解析响应）
- 后端将结果返回给前端，React 组件用状态（
useState）渲染设备列表
这个过程中，Fiber 只负责高效地把后端返回的设备数组渲染成 DOM —— 它不参与“发现”本身。
容易踩的坑：试图在 React 中直接做设备发现
以下操作在标准浏览器环境中必然失败：
- 在
useEffect里尝试用net或dgram模块（Node.js API，浏览器不可用） - 用
fetch('http://192.168.1.100:8080/status')批量扫 IP（会触发 CORS，且多数设备不响应跨域请求） - 假设
Fiber提供了类似findDevices()的方法（它没有，也永远不会有） - 在
ReactDOM.createRoot初始化阶段硬编码设备地址（违背“自动搜寻”前提）
真正要落地，得明确分工：网络探测交给后端或 Electron/TAURI 等具备系统权限的运行时，React 只管呈现。Fiber 的价值，是在列表快速刷新、设备频繁上下线时，不让 UI 卡死 —— 但它不是探测雷达。
