做工业软件之前。
我一直觉得，程序这东西，不就是
输入
处理
输出
有问题就查日志。有异常就看报错。直到后来开始做涂装车间中控、设备联网、PLC 通讯、MQTT 这些东西之后。我才发现：工业项目里最可怕的。不是报错。而是
“它看起来一切正常。”
一、工业现场很多问题，根本没有异常
我印象特别深的一次，现场反馈
“有台车丢了。”
当时我第一反应，是不是数据库没写进去。结果查了一圈：
数据正常
MQTT 正常
PLC 正常
Redis 正常
服务也没挂
但，车的状态就是不对。后来查了很久。发现是 MQTT 消息顺序乱了，先收到出站，后收到进站。于是系统状态直接错乱。最离谱的是：整个过程没有任何异常。日志也全是正常的。
二、后来我越来越怕“时间”
互联网项目里。时间通常只是个字段。工业项目里。时间有时候是命。尤其做统计之后。每天都在处理：
停台时长
生产节拍
实际运行时间
线体开动率
综合可动率
后来我发现：工业现场最恐怖的事情之一。就是
“时间没统一。”
比如，一个地方按秒算，一个地方按分钟算，最后报表直接歪掉。还有一次更离谱，日报统计一直不对。查到最后发现：车间统计周期不是自然日。而是
当天08:00:00 ~ 次日08:00:00后来整整改了两天。
三、工业系统特别容易出现“偶现问题”
这种问题真的能把人逼疯。
比如：
MQTT 偶尔重复消费
程序没报错。
但业务执行了两次。
Redis 锁偶尔不释放
后面的车辆全部卡死。
PLC 某个点位偶尔延迟
状态全乱。
网络偶尔抖一下
设备离线了。
结果其实设备根本没问题。
这种问题最折磨人的地方在于
它不稳定复现。
你现场一去，它好了，你远程一看，它正常，等你下班，它又出问题。
四、我第一次见识 retained 的威力
之前有个 MQTT Topic，负责车辆进站，后来服务重启了一次，结果，半小时前已经过点的车，又重新过了一遍，当时现场直接懵了，后来查了半天，发现，Broker 保存了 retained 消息，程序重新订阅后，Broker 又把最后一条消息推了一次，于是业务重新执行。那一刻我突然理解，为什么工业系统这么怕“重复执行”。因为很多事情真的只能执行一次。
五、工业项目里最怕的，不是挂
而是
“半死不活。”
有时候服务明明在线。但：
MQTT 不消费了
Redis 卡住了
数据延迟了
PLC 状态不更新了
更离谱的是。
Kubernetes 还觉得：
Pod RunningNacos 也觉得：
服务健康但现场已经炸了。所以后来我越来越觉得：工业系统不能只看：
服务在线
端口正常
CPU 正常
因为
业务正常，才是真的正常。
六、工业现场真的没有“重启试试”
互联网项目里。重启一下可能就恢复了。工业现场不一样。因为你根本不知道重启之后：
MQTT 会不会重新推 retained
Redis 锁会不会丢
PLC 会不会重连失败
状态会不会错乱
车辆会不会重复过点
有一次，只是重启了一个服务。结果所有缓存状态全错了。后来查出来：程序启动时重新加载了 Redis 数据，但现场 PLC 状态已经变了。于是，系统认为设备在线，实际上设备已经停了。
七、工业项目特别依赖“现场经验”
后来我发现。
工业项目很多问题。
根本不是代码逻辑问题。
而是
现场逻辑问题。
比如，同样叫“停台”，不同产线含义都不一样，有的，机器人停了算停台，有的，链条停了才算，
还有的，停超过30秒才统计这种东西，没人告诉你文档也不一定写，只能靠现场慢慢磨。
八、工业项目做久了，真的会开始迷信
后来现场甚至出现过一种情况，某个服务：只要晚上重启，第二天一定出问题。一开始大家都觉得扯，后来真查出来：凌晨有个 XXL-Job 在跑统计，同时 Redis 正在主从切换，MQTT 又在重连，三个东西碰一起，概率特别低，但它真发生了，于是现场的人开始说
“别动它，动了准出事。”
九、工业软件最后拼的，其实是“稳定”
现在我越来越觉得，工业项目做到最后，拼的不是：
架构多高级
微服务多漂亮
Kubernetes 多先进
而是
稳不稳定。
因为工业现场一次重复执行，一次误动作，一次状态错乱，代价都特别大。
十、最后一句
现在再有人问我，工业项目为什么像“玄学”，我可能不会说：
分布式
高并发
微服务
我会说
“因为你永远不知道，凌晨三点到底是哪一环出了问题。”
有时候是 MQTT，有时候是 Redis，有时候是 PLC，还有时候，只是现场老师傅手动按了一下按钮。
