美的洗衣机 19 小时上传 411MB：智能家电到底在传什么？我拆了一遍数据链路

一张路由器 App 截图，把美的送上了热搜：一台洗衣机，接入 19 小时 40 分钟，用了 411.52MB 流量。

美的客服的回应是：“智能洗衣机联网不是强制性要求，不连接就不用流量”——没有正面回答"洗衣机在传什么"。

评论区吵成一团：有人说智能家电联网更新软件很正常，有人说这是偷传隐私。作为程序员，这事不该靠猜——411MB/天对一台洗衣机意味着什么，算得出来。

先给量级参照：411MB/天是什么概念

• 微信重度使用：一天约 100-200MB（聊天+图片+视频号）
• 抖音/视频 App：一天 500MB-1GB（纯视频流）
• 正常 IoT 遥测：一天应该在 KB~MB 级（几十个传感器状态点，每次几 KB）

一台洗衣机 19 小时 411MB ≈ 12GB/月。这个量级远超"固件更新"能解释的——固件更新是一次性事件（几 MB 到几十 MB），不是每天持续的。每天 400MB 的节奏，是持续性的数据传输，不是偶发升级。

智能家电的数据链路，拆开看

一台联网洗衣机的流量，一般来自这几路：

① 固件 OTA 更新（合理，低频） 一次几 MB~几十 MB，一个月顶多几次。对不上 400MB/天的量。

② App 远程控制长连接（合理，极低频） 远程看洗涤进度、预约启动，走的是 MQTT/WebSocket 长连接。心跳包几 KB 级，一天下来不到 1MB。这是客服说的"智能预约、查看进度"功能，但这点流量连 400MB 的零头都不到。

③ 统计/广告 SDK（常见，可疑） 设备厂商内置的数据采集 SDK，上报使用行为（几点开机、用了哪个模式、耗电多少）用于产品分析和画像。正常设计应该在 KB~MB 级/天。但如果 SDK 写得糙——每次状态变更全量上报、日志没压缩、批量接口设计成高频轮询——量级会失控。

④ 语音/图像上传（看功能） 如果洗衣机带语音助手或摄像头（部分高端机型有），语音片段和图像上传是流量大头，单条几 MB 到几十 MB。但大部分洗衣机没有这些功能，所以这条通常不成立——除非设备在传一些你根本不知道的东西。

⑤ 日志上报（常见，可疑） 设备端 debug 日志、崩溃日志全量上传。正常应该按需上报（出错才传），但如果实现成"持续流式上传"，一天几百 MB 完全可能。

结论：411MB/天对应的最可能来源是 ③⑤ 的组合——统计 SDK + 日志的持续高频上报，而不是什么"远程控制功能"。功能性的流量（OTA/心跳）撑不起这个量。

一个更值得警惕的点：客服为什么不正面回答

“不联网就不用流量"这个回应，在逻辑上是成立的，但它回避了核心问题：联网状态下，设备在上传什么？

如果只是远程控制，流量应该趋近于零。需要每天 400MB 才能维持的功能，不可能是"查看洗涤进度”——这个量级意味着设备在持续往外送数据，而用户对数据内容没有知情权。

这恰恰是智能家电数据问题的本质：设备的"最小必要"原则没人执行。个保法要求数据采集遵循最小必要，但洗衣机厂商的 SDK 采什么、传什么、存多久，用户完全不知道，客服也说不清。

程序员视角：如果你设计 IoT 遥测，默认姿势应该是这样

写 IoT/后端的人，设计设备上报时应该默认：

1. 数据最小化：只传功能需要的最小字段集。“设备状态"就是开关/模式/进度，不需要传"每次操作的全量上下文”
2. 批量低频上报：遥测数据攒一批再传（比如每 5 分钟或累计 10KB），不要高频轮询、不要每条日志单独一个请求——这是流量失控最常见的原因
3. 可配置可关闭：遥测开关默认开但用户能关，关了不影响核心功能。美的客服那句"不联网就行"其实是把锅甩给用户——正确做法是"联网但可以选择不上传遥测"
4. 压缩 + 差分：日志和状态数据上 gzip，增量只传变化字段。400MB/天的遥测，压缩后应该能降到 1/10 以下

如果一台洗衣机的遥测被设计成"最小必要"风格，一天应该 <5MB。

明天能自查的清单

家里有智能家电的，可以自己查（30 分钟）：

1. 路由器流量统计：登录路由器管理页（如 192.168.1.1），看每个设备的实时/历史流量——找到那台"话多的设备"
2. dnsmasq 日志：OpenWrt 等路由器开 dnsmasq 日志，看设备在解析哪些域名——域名列表就是数据去向的指纹（看到 analytics.、tracking.、stat.* 类域名就要警惕）
3. 抓包：tcpdump -i br-lan host 设备IP 抓 10 分钟，看流量是不是 MQTT（端口 8883/1883）还是 HTTPS 批量 POST——HTTPS 大流量 + 高频 = SDK 上报嫌疑
4. 断外联验证：在路由器把设备加入黑名单/断网，看功能是否受影响。如果只是 App 远程控制不能用、本地洗衣服完全正常——说明"远程控制"本来就是附加项，而它每天 400MB 的传输没有任何功能价值

行业视角：白电"云化"的数据生意

这事的深层背景是：白电厂商都在把硬件生意往"数据生意"转——用户画像、广告推送、服务订阅、甚至卖数据。洗衣机不赚钱，数据才赚钱。

个保法的"最小必要"红线在这里形同虚设，因为：

• 用户装 App 时勾的隐私协议，没人看
• 设备厂商说"为改善产品体验收集使用数据"，但**“改善体验"需要的量级和 400MB/天差着两个数量级**
• 客服没有能力回答"在传什么”，因为可能真的没人知道——SDK 是第三方接的，数据是自动传的

一句话：美的洗衣机的 411MB 不是个例，是智能家居"数据无节制采集"的缩影。对用户，它是隐私问题；对程序员，它是遥测设计失败的教科书案例——只要默认姿势是"最小必要 + 低频批量 + 可关闭"，你写的 IoT 产品就永远不会上这种热搜。

---

搬砖程序员带你飞，专注 Golang / AI / 后端。每天一篇，讲清楚一个技术真相。