刚入行时我做的是嵌入式设备，每天跟串口、寄存器打交道，那时候压根不知道什么叫“物联网平台”，系统里就是一台服务器收数据，前端页面画曲线。等到后来带团队做完整的产品，才发现“平台”两个字背后藏着的东西远比想象中复杂：设备接入、消息路由、规则引擎、数据存储、权限体系、告警通知、OTA升级，每一项单拆出来都是一块不小的工程。

所以在物联网这行待久了，被问到最多的问题永远是：物联网平台到底选哪家？我的回答往往是：别急着看排名，先把你的设备协议、数据规模、团队能力、成本边界画出来，否则再好的平台到你手里也是浪费。

这篇文章不打算像带货榜单一样把各家名字罗列一遍，因为平台的迭代速度太快，你今天记住的版本列表，半年后可能就是另一番样子。我真正想给的，是一套可以复用的选择框架，以及我从实际项目中摸出来的踩坑记录。后面还会带一个从零搭建最小可用平台的过程，手把手把每一步讲清楚。无论你是刚入门想跑通 Demo，还是负责公司产品线的技术选型，这篇文章都能让你少走不少弯路。

1. 先想清楚：你到底需不需要一个“物联网平台”

很多项目一开始其实不需要平台。只有几百个节点、每几分钟上报一次数据，自己写个接口也完全够用。但一旦设备数量破千、上报频率变成秒级，或者要求支持远程配置、告警联动、多用户权限，平台的价值就出来了。

1.1 物联网平台到底解决了什么问题

一句话说清楚：它把“设备如何把数据送进来”和“业务如何把数据用起来”这两件事解耦了。

设备侧不需要关心你的业务系统是什么语言、数据最终进了哪个数据库。它只要按约定协议把消息发上去，平台负责接入、认证、存储、流转。业务侧也不需要对着一堆杂乱报文做解析，只需要订阅标准化的数据接口。

再往细里拆，一个成熟平台通常包含这几块：

• 设备接入层：支持 MQTT、HTTP、CoAP、TCP 私有协议，能完成连接鉴权、心跳维持、断线重连。
• 设备管理：注册、分组、影子模型、OTA 升级、远程控制。
• 数据通道：消息路由、规则引擎，把数据分发给不同的下游系统。
• 数据存储：时序数据、事件记录、设备档案，按不同的生命周期管理。
• 可视化能力：设备地图、指标大屏、历史曲线、告警看板。
• 系统管理：用户体系、角色权限、多租户隔离、操作日志。

这些都是通用能力，但我一直提醒团队：平台解决的是共性问题，不是你的业务问题。真正的差异化，比如设备如何联动场景、数据如何驱动业务流程，永远得自己写。

1.2 没有平台自己也能拼，但成长期不建议

自己拼不是不行。我们早期就自己写过一套：设备走 MQTT 接入，消息进队列，规则引擎用脚本写，数据落数据库，前端自己画图表。东西跑起来之后确实很有成就感，但维护成本大得吓人。

比如设备断线重连后，消息补推怎么做？设备上报的字段变了，后端解析逻辑要不要跟着改？两个设备之间的联锁控制，规则引擎是同步还是异步？每个功能到后期都像一个无底洞，团队被拖在基础设施里，真正业务上的迭代反而慢了。

所以我的建议是：在项目刚起步阶段，或者设备量只有几百台时，自研接入层完全没问题。但当你开始同时关注多协议、高并发、数据治理、权限隔离的时候，别急着重复造轮子，选一个平台先跑起来，把节省的时间花在业务识别上，这样划算得多。

1.3 一张表看懂平台评估的维度

我习惯在选型前先把关注维度列成一张表，每个维度按权重打分。这张表也是后面所有对比的基础。

表格权重不是死的，不同场景会有明显差异。比如纯做园区楼宇，私有化部署和弱电系统对接的权重就很高；做消费类硬件，成本模型和接入速度更重要。把这张表放在桌面上，团队开会时就不会吵来吵去。

2. 推荐前，先建立属于自己的平台评估表

不少人在选平台时喜欢看官网功能清单，功能列表越长越觉得自己赚了。实际用下来发现，这些功能很多都用不到，反而最影响体验的恰恰是那几个高频步骤是否顺手。

2.1 设备接入层：协议越多不代表越强

平台动不动号称支持十几种协议，听起来很厉害。但真正选型时，先问你最关心的三种：MQTT 好不好配、鉴权方式有没有、离线消息怎么处理。这三种才是日常接触最多的。

MQTT 是目前设备接入的事实标准，重点看三件事。

第一，单机连接数能不能撑住你的峰值。很多平台的限制不在协议层，而在连接。比如免费额度只有一万个连接，看似足够，但你的设备如果五分钟重连一次，连接数和频次就会吃掉大量资源。

第二，QoS 的可靠性。设备上报允许丢一条还是必须每条都到？平台有没有把 QoS 1/2 完整落地的能力？有些平台为了性能会悄悄降级，这个在压测里才会暴露。

第三，设备接入的复杂度。是提供设备端 SDK，还是只给一个标准 MQTT 地址？SDK 是否支持你现有的嵌入式环境？很多项目卡死在这：平台能力很强，但设备就是跑不起来，因为芯片内存不够塞 SDK。

表格对比的时候可以把“协议支持数量”和“实际能稳定运行的协议数”分开列。我自己在评估时更喜欢看平台是否允许自定义协议解析，这比支持协议数量重要得多。

2.2 数据处理与规则引擎

设备数据上来之后，平台能不能做基本过滤，直接在边缘侧就完成轻量逻辑。比如温度超过某个阈值，平台能否在毫秒级触发告警并下发指令。规则引擎的易用性决定后期运营效率。

低代码规则拖拽很方便，适合业务同事自己去改。但复杂场景往往需要脚本级能力，尤其是多条件组合、多设备联动、调用外部接口这类操作。纯可视化规则会限制表达力，所以我要看平台上能不能写脚本，脚本有没有超时控制，是否沙箱隔离。

另外要留意规则触发的粒度。是按设备逐条触发，还是按产品模型统一触发？告警频率有没有抖动抑制？这些细节决定告警风暴是不是会在半夜把你叫醒。

很多平台会把规则引擎包装成“场景联动”，看起来很简单，但实际查问题的时候，只能看到触发结果，看不到中间过程。这一块一定要在试用时亲手做一个联动场景，然后故意让它失败，看看日志能不能说清楚失败原因。

2.3 数据存储与可视化

选平台最容易忽略的是历史数据的读取效率。很多平台看起来能存数据，但查询接口很不友好。比如你想查一台设备过去一周的温度曲线，它返回的数据经过聚合，已经把原始明细丢了；你想做一次分析计算，又发现 SQL 能力被限制得很死。

更适合 IoT 的存储是时序数据库，它对时间戳、批量写入、降采样有天然优化。评估时要问三个问题：

• 数据保留策略能不能按设备或者产品配置？比如日志保留三天，监测数据保留一年。
• 有没有原始数据导出接口？可以拉全量明细而不是只能看聚合图。
• 存储扩容是自动还是手动？按消息量付费的模型，会不会出现月底账单爆炸？

可视化不等于平台自带大屏。真正用得最多的是设备列表、状态颜色、实时曲线、告警记录。大屏只是给领导看的，别为它占太高权重。衡量标准只有两个：页面打开快不快，筛选条件好不好使。

2.4 权限、安全和多租户

团队协作时需要区分不同角色：管理员能改配置，运维只看修复，销售只能看自己的设备。平台的权限模型如果太粗，后面业务一多就很痛苦。

安全方面最容易被忽略。设备端密钥泄露怎么办？固件升级如何进行防回滚？通信是否强制 TLS 加密？平台是否支持一机一密？这些不是可选项，而是硬性要求。尤其做联网设备，等出了安全事故再补就晚了。

多租户的隔离也要问清楚。如果你的产品是给多个客户使用的，客户 A 的设备能不能查看到客户 B 的？数据隔离是在应用层做还是存储层做？存储层隔离更稳，但往往成本更高。小规模场景应用层隔离也能接受，但要在合同里白纸黑字写清楚。

2.5 开源还是商业：不是立场问题，是成本问题

开源的诱惑在于代码可控、没 license 成本，商业平台则胜在稳定和生态。实际上两者没有绝对，只有合不合适。

团队有足够的后端能力吗？能给开源平台修 bug、改源码、跟进版本升级？平台上运行的业务将来要依赖哪些扩展点？有没有可能社区版不满足需求、企业版又贵得离谱？

商业平台看着贵，但一般包含工单支持和 SLA 保障。出了故障有人替你扛。开源平台出了问题，只能自己在群里翻 issue。对没人值守的小团队来说，这个隐形成本往往被忽略。

我的实操经验是：先用商业平台的免费额度验证业务模式，等确认需要私有化后再迁到开源方案也不迟。不要一上来就搭一套自托管环境，搞了三个月还没接上几个设备。

3. 三类主流平台怎么选：托管型、开源私有化型、边缘轻量型

这个行业的平台看着五花八门，实际只分出几个派系。每种定位对应不同的需求，选之前先看看自己的处境属于哪一种。

3.1 云托管型：适合快速验证和中小规模

云托管型通常按量付费，几乎不用自己运维服务器，注册账号后就能创建设备产品、生成设备证书、看到在线状态。这种平台最大的价值是快，非常适合原型验证和小批量试点。

它适合什么样的人呢？三五十台设备以内的产品原型，不想在前中期投入服务器维护，希望专注于业务逻辑，或者你根本不打算自己运营基础设施。租用云托管平台是性价比最高的起步方式。

不过别忽视两个问题。首先，连接费和消息费会随着规模非线性上涨，设备量从几千涨到几万时，账单增长可能让你重新做一次选型。其次，数据默认放在平台方机房，如果你的客户有保密要求，这关可能过不去。

所以我通常把云托管型当作“先跑通业务逻辑”的跳板，而不是终极方案。验证完业务价值后，再评估是否需要迁移到私有化或自建方案。迁移时一定要确认数据导出工具的完善程度，不然设备数据会变成你被绑定的筹码。

3.2 开源私有化型：适合有运维能力的团队

开源私有化型最大的吸引力是什么？数据在自己手里，代码在自己手里，扩展逻辑不受平台限制。可以部署到自己的机房，也可以放到云主机上。它的边界由你的资源和能力决定。

适合的使用者是有后端开发能力和运维规范。比如至少有一名熟悉 Linux 和数据库的同事，能独立完成环境搭建、版本升级和问题排查。因为开源平台的文档虽然丰富，但永远不可能像商业厂商那样提供一对一工单支持。

这个模式还有一个隐形优势：可以直接修改平台源码实现定制逻辑。比如在设备接入流程里加入自己的加密网关，或者在规则引擎里补齐特定功能。这种高自由度是商业平台很难做到的。

风险在于后续升级。社区版和商业版的功能会拉开差距，你要么长期停留在老版本，要么投入人力持续同步更新。如果你的团队人数不超过三个人，又没有专人维护基础设施，开局就不推荐走私有化路线。

3.3 边缘侧轻量型：适合本地化和低延迟场景

有些场景对网络的依赖必须降到最低，比如车间内网、医院病区、野外站点。设备数据可能在本地就要完成闭环，不需要上云。这时候一个跑在网关或工业现场的边缘型平台就成了核心。

边缘侧平台通常轻量到可以装进一台小盒子，支持本地存储，断网时继续工作，网络恢复后再把数据补传上去。它同时能对接多种现场总线，比如 Modbus、CAN、OPC UA 这类工业协议。对制造类项目来说，这点比云上那堆花哨功能重要得多。

评估边缘平台时，重点关注离线缓存能力。数据要不要按时间戳去重？补传时机怎么控制？界面交互是否适应触摸屏？另外还要看它怎么和上层平台通信。比较理想的情况是边缘平台本身就是一个数据网关，既能本地展示，又能往中心平台同步数据。

如果项目本身就是纯本地闭环，不需要远程管理，可以优先考虑这一类。不要因为“物联网”三个字就觉得必须上云，现场闭环往往比远程控制更加实用。

3.4 自建组合型：给自己的“平台”攒一台机器的思路

当团队对平台的功能有清晰认识，却发现现成平台处处不合心意时，自建组合型值得认真考虑。它其实不是一个完整平台，而是用一堆成熟组件拼出来的一套最小体系。

我的推荐阵型是：设备接入用一个跑在 Linux 上的消息中间件，规则处理用轻量级脚本或服务程序，数据存储用一个支持时序表结构的数据库，可视化直接写一个简单的 Web 页面。这套系统做完会比你想象中更稳定，因为每一层都是你熟悉的组件。

堆栈的优势是很轻，适合已经有一定后端开发经验、但又不愿意被大型框架绑死的团队。性能上可以针对自己的设备数量和上报频率做专门调优。劣势同样很明显：一切都需要自己维护。

所以如果你评估下来团队还处在快速迭代业务逻辑的阶段，自建组合型可以先放一放。等你发现自己总是在绕开平台做定制的时候，再动手攒也不晚。我自己更多的场景是把自建组合型用作一套给客户演示的“私有化底座”，它的可控感远比商业平台强。

4. 从零搭一个最小可用物联网平台（实操演示）

光说框架没有参考价值。这一节我带你走一遍我用过的最小组合方案，整个过程不需要大型组件，基本能在一台云主机上跑起来。你可以在自己电脑上复现，也可以把它当作业余学习的小项目。

4.1 整体架构定义

我把它设计成三个部分：模拟设备端、接入与处理服务、可视化展示端。设备端通过标准 MQTT 协议上报数据；接入服务负责订阅这些消息，做简单清洗后写入数据库；可视化端从数据库读取数据，渲染曲线和设备状态。

选型原则是“每层只用最少的组件”。消息中间件用一个具备 Web 管理界面的开源 broker；数据库选择一个支持高吞吐写入的时序库；展示端不用前端框架，直接用一个轻量服务返回 JSON，页面用原生 JavaScript 绘制图表。这套组合能让一个新手在今天之内跑通，也方便你后续替换成生产级组件。

目录结构大致这样：

iot-minimal/ ├── device-simulator/ # 模拟设备，循环上报 ├── ingestor/ # 消息订阅与存储服务 ├── web-api/ # 数据查询接口与页面 └── scripts/ # 启动脚本、配置模板

这样的好处是每一层都能独立重启，不像单体应用那样改一行代码就要重新编译整个服务。

4.2 设备端模拟与数据上报

模拟设备很简单。我用 Python 写一个循环，模拟温度、湿度两个指标，每五秒上报一次。这里只演示协议交互逻辑，具体函数名以你使用的 MQTT 客户端库文档为准。

import json import math import time # 这里创建的是 MQTT 客户端对象，不同库的 API 略有差异 client = create_mqtt_client(device_id="dev_001") client.connect("127.0.0.1", 1883) client.loop_start() try: t = 0 while True: temperature = round(20 + 5 * math.sin(t / 10), 2) humidity = round(60 + 10 * math.cos(t / 15), 2) payload = { "device_id": "dev_001", "ts": int(time.time() * 1000), "temperature": temperature, "humidity": humidity, } client.publish("devices/dev_001/telemetry", json.dumps(payload), qos=1) print(f"上报: {payload}") time.sleep(5) t += 5 except KeyboardInterrupt: client.disconnect()

上报时间戳我强制用了设备本地时间转换成毫秒时间戳。这个习惯很重要，后面做曲线展示时，按时间排序才不会乱。平台侧如果有多地部署，时区也要统一处理。

QoS 选 1 意味着消息至少到达一次，避免网络抖动导致丢数据。代价是可能会重复，所以接收端要按设备 ID 和时间戳去重。对于这种模拟场景，协议开销完全可以接受。

4.3 服务端接收、落库和规则触发

接入服务的核心就是一个订阅循环。收到设备消息后，先做格式校验，再补充服务端时间戳，最后写入数据库。这里我省略具体库名，只保留表结构逻辑。

CREATE TABLE telemetry ( device_id VARCHAR(32), ts BIGINT, temperature DOUBLE, humidity DOUBLE, PRIMARY KEY (device_id, ts) );

注意主键用了设备 ID 加时间戳，这样重复上报的同一条数据不会造成脏数据。写入时采用 INSERT 语句，如果违反主键就忽略，天然完成去重。

规则引擎先不引入重型组件，我用一个简单的配置做演示：温度连续三次超过 30 度就打印一条告警，并且在页面状态里标红。

# 告警阈值配置 ALERT_RULES = { "temperature": {"max": 30.0, "times": 3}, } alert_counters = {} def process_message(msg): data = json.loads(msg.payload) device_id, temp, ts = data["device_id"], data["temperature"], data["ts"] key = f"{device_id}:temperature" counter = alert_counters.setdefault(key, []) if temp > ALERT_RULES["temperature"]["max"]: counter.append(ts) # 保留最近三次，看是否连续三次超阈值 if len(counter) >= 3 and ts - counter[-3] < 15000: print(f"[告警] {device_id} 温度连续超阈值: {temp}") else: counter.clear()

这段代码有一个经验点：判断连续三次，不是简单计数，而是结合时间窗口。否则设备重启后会把很久以前的旧记录也算进来，导致误报。实际平台里的规则引擎比这个复杂，但核心判断逻辑一模一样。

4.4 可视化面板与告警验证

最后做一个最简单的页面：左边设备列表，右边实时曲线。后端接口返回最近五分钟的数据，前端收到后用图表库画线。我不准备写完整前端代码，只展示数据接口的返回格式。

{ "device_id": "dev_001", "series": [ {"ts": 1710000000000, "temperature": 23.5}, {"ts": 1710000005000, "temperature": 24.1} ] }

页面上每五秒轮询一次这个接口，就能看到数据像心跳一样一帧一帧冒出来。把告警信息单独过滤成一条列表，超过阈值时设备状态列变红。这一步做完，一个最小可用的物联网平台就闭环了。

整个过程中最容易出问题的不是写代码，而是 MQTT 的 Topic 设计。我在早期项目里用过特别散的 Topic，比如每个设备一个 Topic，规则引擎里全是通配符，后来数据量一大，订阅关系复杂到没人能维护。建议按产品型号、设备 ID、数据类型三层设计，比如{product}/{deviceId}/{metric}，这样扩展分组和权限都会容易很多。

5. 实测踩坑清单：这些坑我替你先踩过了

平台选型和自建过程中，技术问题往往不是最难的，真正让人崩溃的都是那些看起来很小的细节。我在这节整理了五个高频坑，每一个都来自真实经历。

5.1 关于消息丢失与 QoS 的选择

很多人一上来就把所有消息都设成 QoS 2，觉得最保险。实际上 QoS 2 的握手开销是 QoS 1 的好几倍，在大规模场景下会明显拖慢吞吐。更稳妥的做法是：实时性要求高的设备状态上报用 QoS 1，远程控制指令用 QoS 2，纯日志和无关紧要的告警可以用 QoS 0。

还有一个坑是 broker 的重启策略。服务端如果只在内存里维护消息状态，重启后未确认的 QoS 1/2 消息可能丢。部署时务必把持久化打开，给消息中间件配置数据目录，不然每次发布升级都在悄悄丢消息，等运维发现时数据已经断档。

5.2 关于设备影子与状态不一致

设备影子是把设备上报的最新状态缓存下来，供业务端查询。但影子数据经常和设备实际状态不一致。比如你下发了一次重启指令，影子显示“重启中”，设备却因为网络异常没收到，一分钟后影子超时又回到“运行中”。

这个问题的本质是没有把“设备上报状态”和“平台期望状态”分开。我后来在实现里加了第三层“指令下发记录”：一条指令从发出、到达、执行、回报，每一个环节都有独立字段。影子只表示设备最后一次上报的状态，指令状态单独追踪，两者混淆的问题一下子就避开了。

5.3 关于时间戳、字段类型和单位

历史数据里最坑的是单位不一致。有的传感器上报温度用摄氏度，有的用华氏度，测试时没注意，生产环境里一条数据差了 32 度毫不知情。平台无法识别语义，只把数字存下来。所以设备端协议的字段单位必须写死在产品模型里，并在接收端强制校验。

字段类型的问题同样隐蔽。JSON 里的 1 和字符串 "1" 在部分语言里会被隐式转换，但在智能规则中就可能出错。比如判断ph == 7，字符串永远不等于整数 7。这种问题往往要等到报警联动失效才发现，排查起来非常费劲。

5.4 关于设备认证与证书管理

早期做设备接入时喜欢用统一的设备密钥，生产方便，但安全隐患很大。一旦密钥泄露，攻击者可以冒充任意设备上报数据。后面改成一把钥匙一把锁，每个设备使用独立的密钥，生成时只保存设备 ID 和密钥的哈希，设备侧则保存明文。这样即使数据库被拖走，反推设备密钥也极难。

证书按月轮换更是麻烦。轮换太频繁，嵌入式设备没法统一更新；轮换太慢，又怕泄露风险扩大。比较好的办法是支持双证书：一个短期证书用于日常连接，一个长期证书用于签名更新。设备启动后先尝试短期证书连接，失败再用长期证书下线更新。

5.5 关于告警风暴和流控

告警风暴是所有 IoT 系统上线初期都会遇到的。设备离线告警、数据超阈值告警、链接波动告警，短时间内冲进来几百条，微信和短信接口被打爆，紧接着还会有运营商限制。后来我引入了三类机制：防抖、聚合、分级。

防抖指的是同一设备同一告警在一段时间内只发一次，比如五分钟内置为已通知状态。聚合是把同一机柜或同一区域的多个告警合并成一条通知。分级则是区分“可恢复的警告”和“需要人工介入的严重故障”。这一套下来，告警量能下降 80% 以上。

告警恢复也需要单独处理。由于网络波动，设备离线几秒又自动恢复，这种短暂离线不应该触发任何通知。只有超过设定时才认为真离线，恢复时记录时间即可。否则运维每天都会收到几十条假警报，大家很快就会对告警麻痹，真正的故障反而被忽略。

6. 给不同团队的三套推荐菜单

前面讲了评估维度和实操路径，最后把结论落下来，给三类典型团队一套可以直接抄作业的推荐菜单。

6.1 入门学习者：最低成本跑通 Demo

如果你是想学习物联网平台工作原理，预算基本为零，推荐直接选择一套开源私有化组合，在本地虚拟机里按我第四节的方式从零搭一遍。不用买设备，写一个模拟器就够了。

学习重点不是把平台跑起来，而是搞懂每一条数据从设备端到底层存储的完整生命周期。建议把 MQTT 抓包工具开着，观察连接、订阅、发布、确认这些环节的消息交互。跑通后做一些破坏性实验：主动断开设备，看平台如何标记离线；篡改时间戳，看数据处理如何反应。

这个阶段不需要追求大而全，更不要纠结某个平台界面的美观程度。你真正要建立的是数据流思维，能清楚说出“设备上报之后发生了什么”，这比记住任何平台的按钮位置都重要。

6.2 小产品团队：稳定优先、控制成本

团队在做真实产品，设备量几百到几千，有基本的后端支持，那么云托管型是首选。你可以用免费额度快速上线，验证产品逻辑和数据模型是否合理。但建议把免费额度看成试用期，一开始就要规划好付费套餐和迁移路径。

上线前重点测试连接稳定性、消息重传机制、数据导出接口。如果平台没有全量导出功能，一定要提前开发定时同步任务，每隔一段时间把数据拉回到自己的数据库。这样做既留了备份，也为未来迁移铺路。

从成本角度，控制连接数和消息频率比控制服务器更有效。很多平台按消息条数计费，一个设备每秒上报一次和每五秒上报一次，费用差好几倍。可以先在设备端做数据预处理，把采样和上报分离，降低无谓的消息量。

6.3 有运维体系的中型团队：私有化、可扩展

团队有专门的运维人员和后端研发，对数据主权有明确要求，私有化部署会更合适。你依然可以用云主机托管，但所有基础设施归属自己管理，数据不出自己的账户体系，安全边界也更清晰。

建议上线顺序是先搭最小版本跑两个星期，确认接入、告警、存储都稳定，再扩展到全量设备。不要一开始就把所有模型建全，IOT 的数据模型迭代非常快，太早定型反而会陷入改模型的重重阻力。

扩展性上要关注集群模式。设备几千台时单机足够，到了几万台或者消息量爆发式增长，单机部署无论如何都顶不住。选型时要提前确认平台是否支持多节点分布、消息队列是否可替换、数据库是否具备性能降采样的能力。

7. 最后再提醒几句

我在实际项目里反复验证过这么一句话：物联网平台不是买回来的，是自己用出来的。再完整的平台也要结合你的业务，才会变得顺手。平台没法替你回答“这个上报数据准不准”“这台设备的可靠性如何”，这些还是要靠长期的运营积累。

如果你现在正处在选型阶段，我把个人体会分享给你：先花半天整理一张自己的评估表，哪怕只是用 Excel 写也比你刷三天官网强。然后把最看重的前三个维度做成试用用例，逐个跑通。因为平台真正的体验，只有在你发布一条真实设备消息、写一条告警规则、查一次历史数据的时候，才能感受出来。

最后再分享一个小技巧：不要只盯着平台的功能限制，多关注平台的“退出成本”。能不能一键导出设备列表？历史数据有没有全量接口？ API 是否覆盖了所有功能？把这些答案记录下来，你就能在任何一次平台变化面前从容应对。物联网这行变化很快，但数据永远长在自己手里，这是任何时候都不会过时的原则。