一、上位机开发别只盯着C#语法

很多刚入行的人以为上位机开发就是学C#、画WinForm界面，天天抱着语法书啃，研究设计模式，觉得代码写得漂亮就是合格的工程师。结果第一次去现场调试，电脑上跑得好好的串口程序，到现场PLC都连不上。客户问Modbus功能码03和04有什么区别，寄存器地址为什么要减1，直接卡壳。

工控上位机的本质是用代码解决现场实际问题。C#只是工具，WinForm只是载体。一个能在现场稳定跑的程序，70%的精力花在适配业务逻辑和处理协议交互上，写界面和基础代码只占30%。串口通信原理和Modbus RTU/TCP协议是入门必修课，最好做到不用第三方库手写通信代码。多跟现场电气工程师和设备调试员打交道，搞清楚PLC、变频器、传感器的工作逻辑，比多看十本语法书都管用。

有位工程师第一次独立承接小型生产线数据采集项目，实验室测试全通过，信心满满交付。上线第二天客户打电话说生产线停了一小时，程序卡死了。连夜赶到现场排查，发现是工人碰松了串口线，程序没有任何异常处理，直接死循环。那个月绩效全扣。

工控现场的环境比实验室复杂一百倍。设备突然断电、串口意外断开、网络波动、寄存器返回异常数据、工人误操作，这些在实验室里永远测不全。但程序只要崩一次，不管原因在谁，背锅的永远是写程序的人。核心操作必须加try-catch：串口打开关闭、数据读写、文件操作、网络通信，所有跟外部交互的代码一个都不能漏。串口断开自动重连、设备掉线自动重试、数据异常自动过滤，这些容错机制是基本配置。再加上全局未处理异常捕获，即便出现意外bug也能记录信息优雅退出，不至于弹个系统错误框把操作工吓一跳。

刚入行的时候总嫌自己做的程序界面丑，到处找第三方UI控件，加渐变、动画、炫酷图表。在4K显示器上看着确实精致，结果到了客户现场直接傻眼——工控机是用了5年的老设备，Win7系统，分辨率1024×768，配置极低。程序一打开就卡成幻灯片，控件全错位。客户原话是"我要的是能稳定采集数据的程序，不是花里胡哨的演示文稿"。

工控上位机的使用场景是车间，使用者是调试员和操作工，不是互联网产品用户。他们要的是操作简单、看得清楚、运行流畅。多余的美化效果不仅让程序卡顿，还增加bug概率。优先用WinForm原生控件，兼容性最好，出问题概率最低，什么老工控机都能跑。做好分辨率适配，用Panel分组配合Anchor和Dock属性做界面自适应，覆盖现场最常用的1024×768和1920×1080两种分辨率就行。按钮要大、字体要清晰、操作步骤要少，别搞复杂的多层菜单。

有个真实的教训：客户现场程序每天凌晨出现数据采集异常，白天完全复现不出来。在现场守了三天找不到原因，最后加上全流程日志记录，第二天就定位了问题——凌晨设备自动重启，寄存器地址临时偏移，程序没做数据校验直接采了错误数据。

工控现场90%的问题实验室里复现不出来。没有日志，排查问题全靠瞎猜，既浪费时间又显得不专业。串口收发、寄存器读写、异常捕获、用户操作、程序启停，全流程都要记日志。每条日志必须带时间戳、操作类型、数据内容和异常堆栈，缺一个字段等于白写。用分级日志区分info、warn、error三个级别，排查时快速筛选。按天生成日志文件，自动清理过期日志，别把工控机的硬盘塞满。

接定制单最忌讳三件事：不收定金、不写需求文档、不签合同。有工程师第一次接私单，客户说"功能很简单你先做，做完肯定给钱"。结果开发过程中需求不断膨胀，加了Modbus协议、Excel导出、趋势图，前前后后改了8版，最后只拿到一半钱。定金不低于30%到50%，到账再开工。需求必须书面化，功能清单、交付标准、验收标准、开发周期写清楚让客户确认。需求变更必须重新评估工作量和报价。尾款没清之前只给带水印的demo，钱到了再给源码。

工控圈很小，尤其是一个城市的圈子里翻来覆去就那些人。技术是基础，但人脉和口碑才是长期接到高价值订单的核心。常逛工控论坛和交流群，帮别人解决问题混个脸熟。交付完项目不是结束而是开始，逢年过节发个问候，后续小问题免费帮忙解决，老客户的转介绍比投广告管用得多。