做物联网预算的时候，几乎所有人都只算建设费和前三年的运维费。很少有人问一个问题：这套系统在第八年还活着吗？如果要换，换哪一部分、花多少钱？
这个问题在第五年左右会突然变成一个紧急问题。设备还能用、平台跑不动、新的通信模组买不到了——三个寿命不同步，系统就被迫局部重建。
一、先分开看三个寿命
物联网系统不是一个东西，是三样东西叠在一起，每样有自己的寿命周期：
- 硬件寿命：物理器件能撑多久，跟材料、工艺、环境有关
- 通信制式寿命：运营商的网络还能用多久，跟政策和技术代际有关，你控制不了
- 软件平台寿命：代码还能不能跑、依赖还能不能升级、安全补丁还有没有
这三个周期分别是 5 到 8 年、可能 5 年、3 到 5 年。叠加起来，一套系统的「无大修运行期」大约是 4 到 5 年，之后就需要局部替换。
知道这个数字的意义在于：如果你的项目规划周期是 10 年，那从一开始就要按「中途会换一次」来设计，而不是按「一次建成用十年」来设计。
二、硬件寿命：分类型看，差别很大
不同设备的实际使用寿命差别很大，下面是工程上的经验值（正常环境下、正常维护）：
- 电池供电的传感器：2 到 3 年。不是设备坏了，是电池耗尽。可换电池的设计能延长到 5 年
- 普通传感器（温湿度、液位、压力）：3 到 5 年。便宜的半年就开始漂移，需要定期校准
- 电表、水表：8 到 10 年。设计寿命本来就长，且强制检定周期是 6 到 8 年
- 网关、串口服务器：5 到 8 年。工业级的更长，商用级的 5 年就该考虑换
- 交换机：5 到 8 年。风扇和电源是最先坏的部件
- 摄像机：5 到 8 年。CMOS 老化和红外灯衰减是主要问题
- 服务器：物理机 5 年，云服务器建议 3 年做一次规格评估
有一个容易被忽略的点：环境决定寿命。同样一台网关，装在空调机房里能用 8 年，装在户外弱电箱里（夏天箱内温度能到 60 度）可能 3 年就坏。报价时如果没考虑环境，运维成本会远超预期。
另一个点：停产比损坏更麻烦。一个型号停产之后，坏一台就要换一种新型号，新型号的协议、接口、配置方式可能都不一样。当同一个系统里有三种以上「被迫替换」的型号时，维护成本会突然上升。
三、通信制式寿命：这是你控制不了的那一层
2G 退网是最好的教材。中国移动从 2020 年开始逐步退网 2G，到 2025 年基本完成。这期间大量早期的物联网项目被迫改造——表计、车载终端、共享设备，几百万台设备需要换模组或换整机。
当时的项目方是什么感受？设备本身还是好的，网络没了，等于全部报废。改造一台设备的成本（拆、换模组、重装、调试）通常是新设备价格的一半以上，而且要在限期内完成。
现在的制式寿命大致是这样：
- 2G：已经基本退网，不要再选
- 3G：已经退网或正在退，不要选
- 4G：至少还能用 8 到 10 年。4G 是 LTE，会长期作为物联网的主力承载
- 5G：新建设项目的可选项，成本和功耗还偏高
- NB-IoT：已纳入 5G 标准体系（作为 5G mMTC 场景），长期可用，但要关注运营商的具体支持策略
- LoRa：自建网，不受运营商退网影响。风险在频段政策，目前 470–510 MHz 是开放的
结论：现在做项目，选 4G、NB-IoT 或 LoRa，不要碰 2G 和 3G。如果甲方要求用某个老旧制式（因为现场已有设备），要在合同里写明「制式退网后的改造责任和费用归属」，这是最容易被忽略的条款。
四、软件平台寿命：3 年一次大修
软件不会「坏」，但会「过时」。过时的表现是：依赖的框架不再维护、安全漏洞没有补丁、新设备接不进来、新需求改不动。
几个具体的时间尺度：
- 开发框架：主流框架的大版本支持周期通常是 2 到 3 年（LTS 版本长一些）
- 运行时环境：Node.js、JDK、Python 的每个版本支持期约 3 年，过期后不再有安全更新
- 云平台 API：主流云厂商的 API 兼容期通常是 2 到 3 年，之后可能改签名方式、改返回结构
- 数据库：大版本升级通常 3 到 5 年一次，跨版本升级要停机
这些加起来，意味着平台每 3 到 5 年需要做一次技术栈升级。这次升级不是加功能，是把底层换掉，工作量通常是原开发量的 20% 到 40%。
很多项目在第五年遇到的困境是：平台是五年前的技术栈，要升级就得停服、要重新测试、要重新对接所有设备。而业务方不接受停服，于是就这么拖着，直到某天出了一个必须修的安全漏洞，被迫紧急处理。
避免这个困境的办法只有一个：把升级当成常规工作，每年排一点预算，而不是等到必须做的时候才做。
五、替换成本怎么算：不是简单重买
大多数人算替换成本的方式是「新设备价格 × 数量」。这个算法漏掉了大头。
只换设备
成本 = 设备费 + 施工费 + 调试费。施工费通常是设备费的 50% 到 100%——拆旧、布线、安装、调试，这些人工成本往往超过设备本身。如果一个项目 500 台设备、每台 800 元，设备费 40 万，实际替换成本可能在 60 万到 80 万。
只换平台
成本 = 新平台建设费 + 数据迁移 + 重新对接 + 培训。数据迁移和重新对接这两项最容易被低估，通常是新平台建设费的 30% 到 50%。
举个具体的：3000 台设备、8 种协议的项目，换平台要重新对接这 8 种协议（每种 1.5 到 3 人天）、迁移历史数据（按 TB 算，清洗和转换的工作量很大）、重新配置规则和报表。这些加起来，往往比新平台本身贵。
整体替换
等于重做一遍，但多了一个麻烦：旧系统要在新系统上线期间继续运行，两套系统并行的时间通常是 3 到 6 个月。这段时间的运维成本翻倍。
所以结论是：替换成本远高于建设成本。这也是为什么在设计阶段做分层解耦，比后期优化更值钱。
六、怎么设计，让局部替换不影响整体
三个设计原则，都是在建设阶段就能做的：
原则一：协议抽象层
不要把「Modbus 怎么读」的逻辑写进业务代码里。中间加一层协议抽象，业务层只认「设备 ID + 点位 ID + 值」，不关心数据是怎么来的。
这样做的好处：换设备型号、换通信方式、加新协议，只改抽象层，业务代码不动。一个做过协议抽象的系统，换一种设备接入的工作量是 1 到 2 人天；没做过的，可能是 10 人天。
原则二：数据模型和业务逻辑分离
物模型（设备有哪些点位、什么类型、什么单位）要独立定义，不能硬编码在业务逻辑里。这样加设备、改点位不需要改代码。
这一条对长期维护的影响最大。见过不少系统，加一个新点位要改代码、重新发布，运维人员不敢动，每次都要找原开发。这种系统在第三年就变成了黑盒。
原则三：设备接入和业务功能解耦
接入服务（负责收数据）和业务服务（负责算、告警、展示）分开部署。好处是：换接入方式不影响业务，改业务不影响接入。
成本上，解耦会让初期架构复杂一点，工作量增加 10% 到 15%。但第一次替换的时候就能省回来——不解耦的系统换接入方式，往往要连带改业务。
七、规划的时候该写进方案里的三件事
第一件：明确的技术栈升级周期。不要写「平台可持续升级」这种话，写「每 3 年做一次依赖升级，每次预算 X 万」。有数字才有人排预算。
第二件：设备型号的生命周期管理。记录每种型号的采购时间、预计停产时间。停产前一年做一次批量备件采购，比停产之后高价找货便宜得多。
第三件：制式退网的应对预案。如果用运营商网络，写清楚「若运营商停止该制式服务，改造责任和费用如何分担」。这一条在合同里很重要，2G 退网时吃过亏的项目方都懂。
八、一句话总结
一套物联网系统的「无大修运行期」大约是 4 到 5 年。如果你的规划周期超过 5 年，就要在设计阶段考虑「中途会换一次」，而不是假设它一次建成能用十年。
具体怎么设计分层解耦，可以看 四层架构的通俗解释 和 性能优化与安全防护。运维费用怎么按年算，看 物联网项目每年运维要花多少钱。
如果你正在评估一个新项目的总投入，用 平台容量测算 把平台侧成本算出来，再按「建设费 + 5 年运维 + 1 次局部替换」做十年期的总账，这个数字会比只算建设费更接近真实。做预算的时候多算这一层，评审时能少被问住一次。