边缘还是云端：计算放在哪一侧

「要不要上边缘」这个问题本身问得不太对。边缘不是一个要不要买的东西，而是「这段逻辑放在哪一侧执行」的选择，而且同一个项目里不同逻辑的答案可以不同。

四条判断依据

1. 时延要求：从采集到动作必须在多少毫秒内完成。要求在百毫秒以内、且链路经过公网的，基本只能放在边缘；
2. 断网时必须继续工作的部分：安全联锁、基本的本地控制，这些不能依赖云端可达；
3. 数据量与带宽成本：高频采样的原始数据全量上云，在蜂窝网络下成本很快就不合理，边缘侧先聚合再上传是常规做法；
4. 运维可达性：边缘侧的代码更新比云端难得多，变更频繁的业务逻辑放在边缘会持续付出升级成本。

前两条是硬约束，后两条是成本权衡。实践中常见的划分是：实时控制与安全逻辑在边缘，规则告警可以在两侧都有一份，报表、长期存储和跨站点分析在云端。

边缘侧最容易被低估的成本

是版本一致性。十个站点的边缘节点，可能因为部署时间不同、网络条件不同，运行着三个版本的逻辑。同样的输入在不同站点产生不同结果，而排查时很难想到这一层。

应对办法是把边缘侧的逻辑也纳入统一的版本管理与灰度发布，和设备固件的 OTA 用同一套机制：能查询每个节点当前版本、能分批发布、能回滚。做不到这三点的边缘部署，规模一大就会失控。

规则在两侧都放的情况

同一条告警规则在边缘和云端各有一份，是为了断网时本地仍能告警、联网时云端有完整记录。代价是两份规则可能不一致 —— 有人改了云端忘了改边缘。可行的做法是规则以云端为准、下发到边缘执行，边缘不提供本地编辑入口。牺牲一点灵活性，换取不会出现两套规则。

从哪一侧开始

如果项目初期需求还不稳定，建议先把逻辑放在云端，跑通之后再把确实需要本地执行的部分下沉。反过来做 —— 先在边缘实现、再往云端搬 —— 通常要重写，因为边缘侧的实现往往依赖了本地设备的直接访问。这一取舍在物联网平台解决方案的方案阶段就应当明确。多厂区场景下跨站点分析只能放在云端，这类结构在制造业项目里很常见。