Z4.03.1Cloud dependency设计研究
云依赖会使设备在断网时失能
别名: 云栓设备 · cloud-tethered · 广域网单点
概念解释
许多智能设备把控制面放在云端：指令从手机出发，先到厂商云，再回到家里的设备。于是出现一种反直觉的失效形态——广域网断了（家里 Wi-Fi 一切正常），手机与设备同处一个房间，却控制不了：指令必须绕道家门外的一个服务器，而那条路断了。设备本身完好、本地网络完好，功能瘫痪。
这不同于路由器故障：那是家里网络本身的问题。云依赖说的是更狭义的一类——技术上完全可以本地直达、架构上却选择不。远方的云成了身边设备的单点依赖。
机制
厂商选择云链路有充分的工程与商业理由：NAT 穿透让外网访问无需配置、统一账号体系与语音助手集成、算力与固件更新托管在服务端、使用数据聚合分析。这些好处把控制面自然地吸到云上。
代价是控制链路引入了家门外的串联环节：ISP 故障、光猫故障、厂商云端故障、区域机房事故——任何一环断掉，本地功能跟着瘫痪。串联依赖的可靠性是各环之积，而用户对这些环节既不可见也无从干预。最刺痛的形态是厂商云端自身故障：家里一切正常，全家设备集体失灵，等待一个数千公里外的服务器恢复，用户能做的只有刷新页面。
区分两个故障域是诊断的前提：断的是局域网（Wi-Fi、路由器）还是广域网（入户光纤、ISP、云）。局域网断则一切皆断，无话可说；广域网断时本地网络仍在，本地直控在技术上完全可行——失效纯粹是架构决定。这个区分也是选型时的试金石：拔掉光猫还能不能控制，直接暴露设备的架构归属。
怎么研究
- 故障事件分析：大型云服务商与智能设备厂商的公开故障事件提供了自然实验——宕机期间哪些功能存活、哪些瘫痪，可直接从故障报告与用户反馈中归档。这类分析不依赖部署，且样本真实。
- 架构盘点：对市售设备分类「云必需 / 云可选 / 纯本地」，盘点指标包括：控制指令是否必须经厂商服务器、广域网断开时的功能清单、第三方本地网关能否驱动。盘点结果即行业现状基线。
- 本地优先架构的论证：local-first software（Kleppmann 等 2019）从应用软件层面系统论证了「本地为源、网络为增强」的可行性——软件可以在架构上不依赖常时连接而保持全部核心功能；这套论证可直接映射到设备控制面。
方法论注意点：厂商宣传的「本地控制」与实测经常不符（本地唤醒但云端鉴权、本地指令但云端状态），验证必须以拔网实测为准，不能信规格页措辞。
边界
- 本地执行不等于本地完整。 多数「支持本地控制」的设备仍需要云端完成首次配对、语音技能绑定或远程管理；断网时新设备入网往往不可能。宣称本地能力的设备要按「断了广域网之后还能做什么」实测，而不是按宣传语分类。
- 纯本地有真实代价。 远程访问、异地联动（度假屋监控）、跨厂商场景集成本质上需要中继服务；彻底去云会放弃这些能力。「云依赖有害」的结论只适用于核心功能，不适用于增值功能。
- 语音助手是天然的云依赖点。 唤醒词识别在本地，语义理解历史上多在云端——语音控制的断网存活率取决于语义链路的架构，不能由灯具或开关单方面决定。
怎么落地
- 选型时区分「云可选」与「云必需」协议：开放本地协议（经本地网关驱动的无线协议、局域网直连标准）优先于纯云 API 的设备。
- 核心功能——照明、门锁、温控——要求断广域网仍可本地控制，写进采购与验收标准。
- 家庭网络内保留本地直连路径（本地域名解析、局域网发现），避免「同一房间却要绕地球」的路径。
- 验证办法：拔掉光猫（路由器保持工作），逐设备测试控制、自动化、历史记录三项各自存活还是失效；形成每台设备的断网功能清单。清单里任何一台核心设备控制失效的，就是云依赖缺陷。