簡介一份基于C#開發(fā)的溫度采集上位機程序源碼專為需要掌握上位機開發(fā)、串口通信及傳感器數(shù)據(jù)讀取的開發(fā)者準備。程序圍繞DS18B20溫度傳感器展開涵蓋初始化、溫度讀取、異常過濾、平均值計算、閾值報警等關鍵環(huán)節(jié)并采用多線程將UI與數(shù)據(jù)采集分離整體結構清晰適合初學者對照學習也是中高級開發(fā)者快速搭建類似采集系統(tǒng)的參考模板。資源包為zip壓縮格式共2個文件總大小399KB其中rar文件為核心C#源碼工程html文件為解壓密碼及相關說明便于使用者快速打開工程。已有1281人瀏覽學習說明該資源在工業(yè)自動化、物聯(lián)網(wǎng)溫度監(jiān)測場景中具有不錯的實用價值。通過源碼可同時獲得Windows Forms界面布局、SerialPort串口通信、數(shù)據(jù)持久化存儲等典型實踐有助于系統(tǒng)性提升C#項目開發(fā)能力。1. C# 溫度采集上位機源碼從串口裸數(shù)據(jù)到實時曲線的完整閉環(huán)拿到這份 C# 編寫的溫度采集上位機源碼最直接的用法是接上下位機就能看到實時溫度曲線。下位機每 200ms 通過串口發(fā)一幀數(shù)據(jù)上位機要做的就是把裸字節(jié)解析成溫度值、繪制曲線、落盤存檔再留出歷史查詢的入口。聽起來不復雜真正跑起來斷幀、亂碼、UI 卡死、串口被占用每一個都能讓人折騰一下午。這份源碼把串口通信、幀解析、實時曲線、CSV 存儲和參數(shù)配置串成了完整鏈路適合做環(huán)境監(jiān)測、設備聯(lián)調或產線數(shù)據(jù)采集的開發(fā)者直接改來當基礎工具新手能順著跑通熟手能快速替換協(xié)議和界面。2. 串口鏈路先立住通信參數(shù)、幀協(xié)議與數(shù)據(jù)完整性校驗溫度采集上位機本質上是串口數(shù)據(jù)的消費端。下位機單片機或采集模塊把傳感器測到的溫度按固定幀格式發(fā)出來上位機要做的第一件事是把這條鏈路確認清楚。鏈路參數(shù)對不上后面解析、曲線、存儲全是徒勞。拿到這份源碼我建議別急著點擊運行先把通信參數(shù)和幀協(xié)議逐項核對一遍再開始跑數(shù)據(jù)。2.1 通信參數(shù)怎么定波特率、數(shù)據(jù)位與校驗位常見硬件拓撲有兩種一種是 PT100 或熱電偶經過變送器轉成 RS485 信號接到 USB 轉串口模塊再進 PC另一種是單片機直接采樣 DS18B20 或 NTC把溫度值打包成幀從串口發(fā)出。不管是哪種串口參數(shù)都是由下位機固件決定的上位機只能去適配這和網(wǎng)絡通信里客戶端適應服務端是同一個道理別指望上位機改了參數(shù)下位機就跟著變。參數(shù)常見值適用場景波特率9600抗干擾強長線傳輸優(yōu)先溫度采集完全夠用波特率115200高頻采樣或多設備輪詢時用但對線材質量要求高數(shù)據(jù)位8絕大多數(shù)協(xié)議都是 8 位停止位1常規(guī)配置現(xiàn)場干擾大時個別設備用 2校驗位None協(xié)議內部帶 CRC 時硬件校驗可以關掉校驗位Even部分老工業(yè)儀表默認偶校驗這里有個容易誤判的點如果下位機協(xié)議已經做了 CRC16 校驗硬件校驗位設 None 就夠了再疊一層偶校驗會讓數(shù)據(jù)位多出一個 bit兩邊對不齊反而更亂。確認參數(shù)后數(shù)據(jù)仍然亂碼建議先用串口調試助手抓原始字節(jié)看幀頭是否和協(xié)議文檔一致再判斷是硬件問題還是解析問題不要一上來就懷疑波特率。2.2 SerialPort 的接收寫法事件驅動還是輪詢C# 里讀串口有三種常見姿勢。一是 DataReceived 事件數(shù)據(jù)到達時在后臺線程觸發(fā)回調實時性最好代碼最省二是開一個后臺線程循環(huán)讀配合 ReadTimeout 控制阻塞三是用 SerialPort.BaseStream 做異步讀。多數(shù)溫度采集項目用 DataReceived 就夠了下面的代碼就是這套源碼里的標準寫法。private SerialPort _serialPort; private readonly object _syncLock new object(); public bool InitSerialPort(string portName, int baudRate 9600) { try { _serialPort new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One); _serialPort.DataReceived OnDataReceived; _serialPort.ReadTimeout 200; // 同步 Read 的等待上限防止極端情況卡住后臺線程 _serialPort.Open(); return true; } catch (Exception ex) { Console.WriteLine(串口打開失敗: ex.Message); return false; } } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { SerialPort sp (SerialPort)sender; byte[] buffer new byte[sp.BytesToRead]; int count sp.Read(buffer, 0, buffer.Length); if (count 0) { AppendToBuffer(buffer); // 統(tǒng)一進接收緩沖區(qū)由解析邏輯拆幀 } }邏輯說明OnDataReceived 在后臺線程被調用里面不能直接操作任何 UI 控件。Read 一次把當前緩沖區(qū)里的字節(jié)全部取出BytesToRead 表示此刻串口接收緩沖區(qū)里的字節(jié)數(shù)它并不等于一幀數(shù)據(jù)的長度。數(shù)據(jù)交給 AppendToBuffer 統(tǒng)一入緩沖由后續(xù)拆幀邏輯處理。ReadTimeout 參數(shù)在事件驅動模式下平時用不上但某些驅動在異常狀態(tài)下會導致 Read 阻塞設置一個超時算保險。portName 不要寫死程序啟動時用 SerialPort.GetPortNames() 枚舉當前可用端口做成下拉框讓用戶選。USB 轉串口拔插后 COM 號會變寫死端口是本場景最常見的翻車原因之一。提示GetPortNames() 返回的端口名有時帶硬件描述比如 USB-SERIAL (COM3)解析時只取括號里的 COM 號即可。2.3 幀協(xié)議與校驗CRC16 計算和緩沖區(qū)拆幀串口是流式協(xié)議不保證一次收到完整一幀上位機必須自己維護緩沖區(qū)按幀協(xié)議做字節(jié)對齊。這套源碼里的幀格式如下AA 55 幀頭設備地址 1 字節(jié)溫度數(shù)據(jù)兩個字節(jié)高字節(jié)在前最后是 CRC16 低字節(jié)在前、高字節(jié)在后的雙字節(jié)校驗整幀 7 字節(jié)。幀頭選 AA 55 這類在二進制數(shù)據(jù)里出現(xiàn)概率低的組合能明顯降低誤判。public static ushort Crc16Modbus(byte[] data, int length) { ushort crc 0xFFFF; for (int i 0; i length; i) { crc ^ data[i]; for (int j 0; j 8; j) { if ((crc 0x0001) ! 0) crc (ushort)((crc 1) ^ 0xA001); else crc 1; } } return crc; }邏輯說明這是 Modbus RTU 標準的多項式算法初始值 0xFFFF。調用時傳入幀中除去校驗字節(jié)的部分即前 5 個字節(jié)算出的結果與幀尾 2 字節(jié)比較一致才認為這一幀有效。CRC16 能檢出單比特和大部分多比特錯誤工業(yè)現(xiàn)場強烈建議保留不要圖省事用所有字節(jié)求和取低 8 位的累加校驗抗干擾能力差一個量級。拆幀邏輯集中在一個循環(huán)里完成核心代碼如下private Listbyte _recvBuffer new Listbyte(); private void AppendToBuffer(byte[] data) { lock (_syncLock) { _recvBuffer.AddRange(data); TryParseFrame(); } } private void TryParseFrame() { const int FRAME_LEN 7; while (_recvBuffer.Count FRAME_LEN) { int headIndex _recvBuffer.IndexOf(0xAA); if (headIndex 0) { _recvBuffer.Clear(); // 連幀頭都沒有清掉避免內存膨脹 return; } if (headIndex 0) { _recvBuffer.RemoveRange(0, headIndex); } if (_recvBuffer.Count FRAME_LEN) { return; // 幀頭已找到但數(shù)據(jù)不完整等下一批 } if (_recvBuffer[1] ! 0x55) { _recvBuffer.RemoveAt(0); // 第二字節(jié)不是幀頭丟一個字節(jié)重新對齊 continue; } ushort calcCrc Crc16Modbus(_recvBuffer.ToArray(), 5); int low _recvBuffer[5]; int high _recvBuffer[6]; ushort recvCrc (ushort)((high 8) | low); if (calcCrc ! recvCrc) { _recvBuffer.RemoveAt(0); // 校驗失敗丟掉當前字節(jié)繼續(xù)對齊 continue; } byte address _recvBuffer[2]; short rawTemp (short)((_recvBuffer[3] 8) | _recvBuffer[4]); double temperature rawTemp * 0.1; OnFrameParsed(address, temperature); // 觸發(fā)業(yè)務事件 _recvBuffer.RemoveRange(0, FRAME_LEN); // 消費掉完整幀 } }邏輯說明IndexOf 定位幀頭 0xAA幀頭前的殘留字節(jié)直接清掉幀頭后第二字節(jié)不是 0x55 就丟掉一個字節(jié)繼續(xù)找?guī)^匹配且長度夠 7 字節(jié)后先算 CRC16對不上就丟第一個字節(jié)重新對齊而不是整段清空——這樣最多丟一幀不會把后面連續(xù)有效的數(shù)據(jù)全廢掉。解析完成后通過 OnFrameParsed 事件拋出去上層只關心溫度值不碰字節(jié)邏輯。這個循環(huán)里 while 而不是 if 是關鍵。如果緩沖區(qū)里同時到了兩幀半的數(shù)據(jù)while 會連續(xù)消費掉完整幀直到剩余字節(jié)不夠一幀才退出。真遇到頻繁誤判先懷疑協(xié)議設計幀頭選得太常見比如 0xFF就必須改用更長幀頭或加設備地址預校驗。3. 溫度解析與實時展示從 byte[] 到 Chart 控件的完整實現(xiàn)鏈路通了之后核心就是三件事解析、展示、存儲。這一章按數(shù)據(jù)流向展開把溫度值怎么從兩個字節(jié)變成人看得懂的曲線和表格講清楚。解析層保持獨立是最重要的——不要在前面 TryParseFrame 里直接寫 UI 代碼否則后面加存儲、加多通道都會被迫改動拆幀邏輯。3.1 溫度值解析字節(jié)拼接、符號位與單位換算溫度數(shù)據(jù)在串口幀里通常以定點數(shù)傳輸而不是浮點數(shù)。原因是浮點數(shù)占 4 字節(jié)且字節(jié)序在不同平臺上容易出錯定點數(shù)用 short 表示單位 0.1°C解析簡單還省帶寬。上面幀協(xié)議里 rawTemp 是帶符號 short范圍 -32768 到 32767乘 0.1 后能覆蓋 -3276.8°C 到 3276.7°C對溫度采集綽綽有余。private double ParseTemperature(byte highByte, byte lowByte) { // 高低字節(jié)拼成帶符號 16 位整數(shù)單位 0.1°C short raw (short)((highByte 8) | lowByte); double celsius raw * 0.1; // 合理性過濾把明顯越界的值擋在業(yè)務層外面 if (celsius -50 || celsius 150) { return double.NaN; // NaN 在曲線和表格里會被跳過不畫出毛刺 } return celsius; }邏輯說明(highByte 8) | lowByte 是大端序拼接如果下位機發(fā)的是小端序低字節(jié)在前要改成 (lowByte 8) | highByte。C# 的 short 是帶符號的若下位機用 ushort 表示溫度0xFFFF 是某個大正數(shù)而不是 -1就必須換成 ushort 再轉 double。還有一點容易踩byte 在運算時會隱式提升為 int(highByte 8) 的結果是 int直接賦給 short 需要顯式強轉不然編譯報錯。合理性過濾這塊很多人想省但實際非常有用。工業(yè)現(xiàn)場偶爾會出現(xiàn)設備上電瞬間的異常值或者通道懸空時的 0xFFFF如果不擋曲線圖上會蹦出一根直插天際的毛刺回放歷史數(shù)據(jù)時特別扎眼。過濾閾值按你實際的量程范圍設不一定非用 -50 到 150。3.2 Chart 實時曲線滾動窗口與跨線程刷新WinForms 的 Chart 控件畫實時曲線核心是兩點跨線程更新和點數(shù)裁剪。跨線程問題在事件驅動的串口讀取里必然出現(xiàn)因為 OnDataReceived 跑在后臺線程直接操作 chart1.Series 會拋跨線程異?；蚺及l(fā)崩潰。chart1 上需要先建一個名為 Temperature 的 Series可以在窗體設計器里加也可以在 Load 事件里用 chart1.Series.Add(Temperature) 創(chuàng)建。private void UpdateChart(double temperature, DateTime time) { if (chart1.InvokeRequired) { chart1.Invoke(new Action(() UpdateChart(temperature, time))); return; } Series series chart1.Series[Temperature]; series.Points.AddXY(time, temperature); // 滾動窗口最多保留 3000 個點超出后從頭部刪 while (series.Points.Count 3000) { series.Points.RemoveAt(0); } // X 軸跟隨最新時間滾動只顯示最近 5 分鐘 DateTime maxTime time.AddSeconds(5); chart1.ChartAreas[0].AxisX.Maximum maxTime.ToOADate(); chart1.ChartAreas[0].AxisX.Minimum maxTime.AddMinutes(-5).ToOADate(); }邏輯說明InvokeRequired 判斷當前線程是否和創(chuàng)建控件的線程一致不一致就用 Invoke 把更新切回 UI 線程。這個模式是串口上位機里最穩(wěn)妥的跨線程寫法比手動維護 delegate 簡單。AddXY 的 X 軸值是 DateTimeChart 控件內部會轉成 OADate 數(shù)值所以手動設置 AxisX.Maximum/Minimum 時也要先 ToOADate()否則軸范圍設置會錯位。點數(shù)裁剪用 while 循環(huán)刪頭部。實際性能瓶頸不在刪點而在 Chart 控件重繪所以更新頻率要控制。如果每幀都觸發(fā)曲線刷新200ms 一幀就是每秒 5 次能跑但沒必要。我一般會加一個刷新節(jié)流數(shù)據(jù)解析和存儲逐幀完成UI 用 System.Windows.Forms.Timer 每 500ms 拉一次最新值刷曲線和數(shù)值框。這樣做還有一個附帶好處UI 刷新頻率和數(shù)據(jù)采樣頻率解耦之后要調采樣率不用動界面代碼。3.3 數(shù)據(jù)落盤CSV 高頻寫入的緩沖策略溫度采集是長時間運行的任務數(shù)據(jù)落盤不能每幀都打開文件寫一次磁盤 IO 會成瓶頸SSD 也被頻繁小寫傷到。常規(guī)做法是內存里攢夠一批再寫代碼里用 StringBuilder 做緩沖。private StringBuilder _csvBuffer new StringBuilder(); private int _csvBufferedCount 0; private const int FlushThreshold 100; // 攢夠 100 條寫一次文件 public void AppendCsvRecord(DateTime time, double temperature) { if (double.IsNaN(temperature)) return; // 過濾后的異常值不落盤 _csvBuffer.AppendLine( string.Format({0:yyyy-MM-dd HH:mm:ss.fff},{1:F2}, time, temperature)); _csvBufferedCount; if (_csvBufferedCount FlushThreshold) { File.AppendAllText(_csvPath, _csvBuffer.ToString(), Encoding.UTF8); _csvBuffer.Clear(); _csvBufferedCount 0; } } public void FlushCsv() { if (_csvBuffer.Length 0) { File.AppendAllText(_csvPath, _csvBuffer.ToString(), Encoding.UTF8); _csvBuffer.Clear(); _csvBufferedCount 0; } }邏輯說明File.AppendAllText 每次調用會打開、寫入、關閉文件一次100 條一攢就是把 100 次 IO 合并成 1 次。FlushCsv 必須在窗體關閉時調用否則最后不足 100 條的數(shù)據(jù)會丟。文件名建議帶日期比如 Temperature_20250712.csv一天一個文件后續(xù)歸檔和按月整理都很方便。長期運行且有查詢需求的項目可以換成 SQLite但如果交付目標只是讓用戶能用 Excel 打開數(shù)據(jù)CSV 是最省事的。提示程序被任務管理器強殺時緩沖區(qū)里未落盤的記錄會丟。數(shù)據(jù)完整性要求高的場景把閾值降到 20 左右再配合進程退出時的 Flush 兜底。4. 踩坑與排查串口亂碼、斷幀、UI 卡死等五個高頻問題溫度采集上位機項目不大但坑極多而且很多坑只在跑了一兩個小時甚至過夜后才暴露。下面五條是這套源碼對應場景里最高頻的問題每條按現(xiàn)象、原因、解決三部分拆開寫調試時可以直接對著查。4.1 串口層的三個坑亂碼、斷幀與設備掉線坑一解析出來的溫度偶爾跳變曲線帶毛刺現(xiàn)象溫度值大部分時間正常但每隔幾秒冒出一個 -273.15 或 65535 之類的異常值回看 CSV 也能找到這些臟數(shù)據(jù)。原因兩種情況。一種是上位機把串口數(shù)據(jù)當字符串讀了用 Encoding.ASCII 或 Default 去解碼二進制幀字節(jié)對不上自然亂另一種是下位機發(fā)送的數(shù)據(jù)里那一幀本身就是設備上電或復位瞬間的未定義值上位機沒做合理性過濾。解決二進制幀全程用 byte[] 處理任何環(huán)節(jié)都不要轉 string。解析側保留合理性過濾超出物理范圍的值直接返回 NaN 丟棄。還有一個檢查技巧把異常值出現(xiàn)的時刻和下位機設備日志對比如果每次都出現(xiàn)在上電瞬間說明是設備側問題上位機只需要做到不把臟數(shù)據(jù)畫上曲線?？佣粠瑪?shù)據(jù)被拆成兩三次收到解析大面積失敗現(xiàn)象DataReceived 觸發(fā)時 BytesToRead 只有 3~4 個字節(jié)如果按收到字節(jié)即完整幀去解析每次都差幾個字節(jié)日志里全是解析失敗記錄。原因串口是流式協(xié)議字節(jié)到達時間取決于發(fā)送方和驅動事件觸發(fā)的是有數(shù)據(jù)可讀不是一幀完整到達。解決緩沖區(qū)累積模式每次讀到的字節(jié)先追加再去緩沖區(qū)里找完整幀對應本章 TryParseFrame 的 while 循環(huán)邏輯。幀頭找到了但長度不夠就等下一批字節(jié)。接收緩沖區(qū)要加超時清空策略超過 2~3 秒沒有新數(shù)據(jù)把半截幀丟棄否則設備重啟后發(fā)的第一幀會和殘留字節(jié)拼成錯幀?？尤诖虿婚_或者跑著跑著設備掉線現(xiàn)象程序啟動時 Open() 拋異常提示端口被占用或者 USB 轉串口連接的下位機半夜斷連第二天早晨數(shù)據(jù)斷檔一整段。原因端口被占用多數(shù)是上一次程序異常退出時沒釋放掉線的元兇經常是 Windows 電源管理把 USB 設備休眠了USB 轉串口芯片和電腦之間的連接被系統(tǒng)掐斷。解決Open() 用 try/catch 包裹并在界面上給出明確提示程序退出時釋放串口資源代碼里統(tǒng)一寫在窗體關閉事件里。protected override void OnFormClosing(FormClosingEventArgs e) { if (_serialPort ! null _serialPort.IsOpen) { _serialPort.Close(); _serialPort.Dispose(); } FlushCsv(); base.OnFormClosing(e); }同時在設備管理器里把對應 USB 根集線器的允許計算機關閉此設備以節(jié)約電源勾掉。代碼層面再加一層防護定時發(fā)心跳查詢命令超過 N 秒沒回應就自動重連這個邏輯對長時間無人值守的采集站是剛需比人工半夜起來拔插 USB 靠譜得多。4.2 界面層的兩個坑UI 卡死與曲線內存暴漲坑四程序跑起來界面卡頓拖窗口像幻燈片現(xiàn)象數(shù)據(jù)刷新看著正常但界面響應極差鼠標拖動窗口延遲明顯點下拉框要反應半天。原因跨線程更新沒正確編組或者解析存儲邏輯直接放在 UI 線程。DataReceived 回調里如果同步操作 Chart、TextBox后臺線程和 UI 線程互相搶資源界面就被拖死。解決解析和存儲全放后臺線程UI 只根據(jù)最新溫度值刷新?？缇€程統(tǒng)一用 InvokeRequired Invoke 模式更推薦的做法是定時器節(jié)流刷新500ms 更新一次數(shù)值和曲線UI 線程負載降下來整個程序就順了。還有一個容易被忽略的細節(jié)串口調試階段加的 Console.WriteLine 在頻繁調用的路徑上會拖慢程序正式跑之前記得刪掉或注釋。坑五跑一晚上內存漲到幾個 G最后崩掉現(xiàn)象程序啟動時內存 50MB運行 8 小時后到 3GB曲線越來越遲鈍最終無響應。原因Chart 控件的 Points 無限累加畫了幾十萬個點也不做裁剪同時每次刷新時反復綁定 DataSource強制控件全量重繪內存和 CPU 一起爆。解決限制 Points 數(shù)量超出滾動窗口就 RemoveAt(0)刷新用定時器節(jié)流繪制用 AddXY 追加避免重復綁定 DataSource。如果采集頻率很高比如 10ms 一幀建議把歷史數(shù)據(jù)落盤后從曲線里淘汰曲線只保留最近時間段全量數(shù)據(jù)交給 CSV 或數(shù)據(jù)庫別讓 UI 控件扛全量。5. 進階落地離線回放、多設備輪詢與 CSV 導出的三個實戰(zhàn)技巧鏈路穩(wěn)定跑起來之后有三件小事能讓它從能用的工具變成省事的生產工具。都是小改動但日常維護和排查問題時的體驗完全不一樣。5.1 原始字節(jié)留檔排查現(xiàn)場問題的后悔藥private FileStream _rawLogStream; private void InitRawLog() { string file raw_ DateTime.Now.ToString(yyyyMMdd_HHmmss) .bin; _rawLogStream new FileStream(file, FileMode.Append, FileAccess.Write); } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { SerialPort sp (SerialPort)sender; byte[] buffer new byte[sp.BytesToRead]; int count sp.Read(buffer, 0, buffer.Length); if (count 0) { _rawLogStream.Write(buffer, 0, count); // 原始字節(jié)留檔 _rawLogStream.Flush(); AppendToBuffer(buffer); } }現(xiàn)場數(shù)據(jù)對不上、曲線莫名跳變的時候手里有原始字節(jié)流就能在開發(fā)機上離線重放復現(xiàn)解析邏輯的問題不用跑到現(xiàn)場接設備盲猜。二進制日志按天切換文件名避免單文件過大?；胤艜r把文件里的字節(jié)按同樣節(jié)奏喂給解析函數(shù)配上時間戳打印問題定位很快。5.2 多設備擴展按地址分表管理前面幀協(xié)議里的第二字節(jié)是設備地址。要接多路溫度不需要改串口鏈路只要在解析層加一個字典把不同地址的幀分發(fā)到不同通道。private Dictionarybyte, ChannelData _channels new Dictionarybyte, ChannelData(); private void OnFrameParsed(byte address, double temperature) { if (!_channels.ContainsKey(address)) { _channels[address] new ChannelData(address); } _channels[address].Push(temperature); }ChannelData 內部維護自己的曲線序列和 CSV 文件界面列表按行刷新即可。要注意如果下位機是上位機發(fā)查詢命令才回數(shù)據(jù)的請求應答模式還需要加一個查詢隊列輪流發(fā)送查詢幀每個通道一個超時計時器超時重發(fā)兩次再標記斷連。這套邏輯加進去后單機掛載的通道數(shù)取決于波特率和輪詢周期9600 波特率下輪詢 8 個通道、每通道秒級更新是可以接受的。5.3 CSV 導出 Excel 不亂碼BOM 頭那點事用 UTF-8 編碼直接寫 CSV在 Excel 里打開大概率亂碼因為 Excel 默認按本地 ANSI 碼頁解碼。解決方法是文件開頭寫一個 BOM 標記。File.WriteAllText(path, \uFEFF csvContent, Encoding.UTF8);\uFEFF 是 UTF-8 的字節(jié)序標記。加了它Excel 能正確識別編碼中文表頭和溫度數(shù)值都正常顯示。如果交付對象明確要求 GB2312用 Encoding.GetEncoding(GB2312) 寫也可以但默認情況下優(yōu)先 UTF-8 with BOM跨平臺兼容性更好記事本、WPS、Excel 都能正確打開。從那以后我每次寫串口上位機都把原始字節(jié)留檔列為第一步哪怕協(xié)議再簡單也先抓幀再寫解析。少了現(xiàn)場往返的折騰也少了很多看起來對不上號的玄學問題。這套源碼的工程文件、協(xié)議注釋和配置示例是配套的按這篇的順序把端口參數(shù)和幀協(xié)議改成一比一對應再處理好 UI 刷新策略基本就能穩(wěn)定跑起來。希望幫到你。本文還有配套的精品資源點擊獲取