簡介C# WinForm開發(fā)的超市收銀POS系統(tǒng)完整源碼及配套SQL數(shù)據(jù)庫腳本面向需要學習桌面端業(yè)務(wù)系統(tǒng)開發(fā)、或希望快速搭建零售收銀解決方案的開發(fā)者。系統(tǒng)覆蓋商品管理、銷售處理、庫存跟蹤、報表生成、多方式收銀結(jié)賬、用戶權(quán)限管理、數(shù)據(jù)備份恢復等核心功能從數(shù)據(jù)庫設(shè)計到界面交互形成一套可運行參考方案。壓縮包共90個文件以28個C#源文件為主另含SQL建庫腳本、xsd數(shù)據(jù)集定義、resx界面資源、EntityFramework依賴組件及項目配置文件等包體約12.02MB目錄結(jié)構(gòu)完整便于直接加載調(diào)試。資源已有87人學習下載。通過源碼可學習WinForm窗體布局、數(shù)據(jù)綁定、業(yè)務(wù)分層處理與SQL交互的實踐寫法借助初始化腳本可快速還原數(shù)據(jù)庫結(jié)構(gòu)理解商品、訂單等表間關(guān)系適合課程設(shè)計參考、入職練手或基于實際需求做二次功能擴展。1. C# WinForm 超市收銀系統(tǒng)2025年還在用圖的不是先進而是省事你把標題掃了兩遍才確認“收營”是“收銀”的錯別字。這種錯別字在國內(nèi)中小型項目里太常見了它往往不是筆誤而是一個不太懂開發(fā)的人在需求文檔里隨手打的后面照著翻譯成代碼的人也沒糾正。2025年掏出一套 C# WinForm 超市收銀系統(tǒng)聽起來有點老土但它能活下來的理由恰恰很現(xiàn)實幾乎所有 Windows 電腦都能雙擊運行不需要 IIS、不需要 Linux 服務(wù)器、不需要容器數(shù)據(jù)庫一臺 SQL Server 就能扛住日流水幾千單的小超市。這套系統(tǒng)的價值不在技術(shù)棧炫技而在把一類需求完整走通——登錄與權(quán)限、商品檔案與庫存、前臺掃碼結(jié)算、銷售報表。你拿到源碼和 SQL 文件不是跑起來就算完而是能看懂每一步之間怎么銜接、哪些地方容易埋雷。適合兩類人一類是想靠完整項目練手的學生另一類是給自家小店或朋友門店搭收款系統(tǒng)、預算有限又不想為 SaaS 年費掏錢的店主。2. 把模塊先切開再落庫設(shè)計超市收銀系統(tǒng)的功能邊界與訂單結(jié)構(gòu)2.1 收銀鏈路拆成四個功能域各管各的別混在一個窗口里動手寫代碼前我一般會先在紙上把功能域畫出來。超市收銀系統(tǒng)最常見的錯誤是把“商品維護”“庫存查詢”“收銀結(jié)賬”“報表統(tǒng)計”全塞進一個主窗口加十幾個 TabPage寫著寫著代碼就變成一坨。常見做法是拆成四個域基礎(chǔ)檔案管理商品、供應(yīng)商、會員庫存中心管入庫、出庫、盤點收銀臺管掃碼、結(jié)算、小票報表中心管日結(jié)、月結(jié)和趨勢。四個域的數(shù)據(jù)流是一條直線商品檔案先建好庫存才有據(jù)可加收銀臺才能扣減報表再匯總。數(shù)據(jù)流一旦畫清楚數(shù)據(jù)庫表結(jié)構(gòu)也就跟著確定下來。基礎(chǔ)檔案是源頭庫存是中間狀態(tài)訂單是結(jié)果。很多新手把“庫存”當成一張靜態(tài)表每次收銀直接改庫存字段這樣做月底對賬遲早對不上因為缺少流水。庫存域至少要有一張庫存臺賬和一個流水表實收實發(fā)都留痕。商品表只存當前庫存量流水表記錄每一次變動這是后續(xù)做報表和盤點的基礎(chǔ)。另外要注意窗口之間的數(shù)據(jù)傳遞。WinForm 里最常見的方式是登錄成功后把用戶 ID 和用戶名放在一個靜態(tài)會話類里而不是到處打開數(shù)據(jù)庫連接重新查。會話類雖然簡單但要控制好生命周期退出登錄時清空否則切換賬號后會串身份。這個小細節(jié)在多人共用一臺收銀機的超市里非常容易出現(xiàn)兩個店員交接班不退出后一個人用前一個人的權(quán)限登錄問題就大了。2.2 訂單主表與訂單明細表一單一品用 SQL 建出最穩(wěn)的關(guān)系收銀系統(tǒng)的核心表不是商品表而是訂單主表和訂單明細表。一張小票對應(yīng)一個主表記錄票面上的每一行商品對應(yīng)明細表的一條記錄。為什么不能把商品直接拼成一個字符串塞進一個字段里因為后續(xù)要做銷售統(tǒng)計、退換貨、按品類分析拆開存才能用 SQL 高效聚合。主表存訂單號、收銀員、會員、折扣、應(yīng)收實收、支付方式、下單時間明細表存訂單號、商品 ID、商品名稱、數(shù)量、單價、小計。注意明細表里的商品名稱要冗余一份商品改名或刪除后歷史訂單仍能還原。下面是建表腳本的核心片段我在 SQL Server 2012 到 2022 上都用過同一套寫法CREATE TABLE dbo.invoice_header ( invoice_no VARCHAR(24) NOT NULL, -- 訂單號業(yè)務(wù)生成帶日期前綴 user_id INT NOT NULL, -- 收銀員ID member_id INT NULL, -- 會員ID未登錄可為空 discount_amt DECIMAL(10,2) NOT NULL DEFAULT 0, -- 整單折扣金額 total_amt DECIMAL(10,2) NOT NULL, -- 應(yīng)收總額 pay_amt DECIMAL(10,2) NOT NULL, -- 實收金額 pay_type TINYINT NOT NULL DEFAULT 1,-- 1現(xiàn)金 2微信 3支付寶 create_time DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT pk_invoice_header PRIMARY KEY (invoice_no) ); CREATE TABLE dbo.invoice_line ( id BIGINT IDENTITY(1,1) NOT NULL, -- 行號自增 invoice_no VARCHAR(24) NOT NULL, product_id INT NOT NULL, product_name NVARCHAR(120) NOT NULL, -- 冗余商品名稱防止歷史訂單失真 quantity DECIMAL(10,2) NOT NULL, -- 數(shù)量保留兩位支持稱重商品 price DECIMAL(10,2) NOT NULL, -- 成交單價 sub_total DECIMAL(10,2) NOT NULL, CONSTRAINT pk_invoice_line PRIMARY KEY (id), CONSTRAINT fk_line_header FOREIGN KEY (invoice_no) REFERENCES dbo.invoice_header (invoice_no) );訂單號我不用自增主鍵而是用業(yè)務(wù)流水號比如20250113120045 收銀臺編號 三位流水。這樣好處是兩臺收銀機同時下單不會撞號報表按時間查也方便。但要用它做主鍵就必須保證在代碼里生成時不重復常見做法是用日期加隨機后綴或者用一個獨立的序列表每次取出下一個序號。簡單的門店系統(tǒng)用日期加收銀臺編號加三位循環(huán)號就夠前提是單臺收銀機下單量不大。數(shù)量字段用DECIMAL(10,2)而不是INT因為超市有稱重商品0.55 千克的蘋果按 0.55 計算四舍五入到整數(shù)會在日結(jié)對賬時差出幾毛錢累積一個月就成了大問題。2.3 連接串、字符集與主鍵策略三個在建庫前就要定下來的參數(shù)很多人的 SQL 文件導入失敗翻車點不在業(yè)務(wù)表而在最開始幾個參數(shù)。字符集建議用Chinese_PRC_CI_AS它是簡體中文常用的排序規(guī)則直接用默認的Latin1_General會出現(xiàn)中文字段排序不按拼音、部分漢字顯示異常的問題。數(shù)據(jù)庫所有表的主鍵和索引放在同一個文件組就行不需要為小型超市做文件組拆分拆了反而增加備份復雜度。連接串是另一個高頻踩坑點。WinForm 程序里連接字符串建議寫在App.config中而不是硬編碼在代碼里。這樣換電腦部署時只需要改配置不用改代碼重新編譯。?xml version1.0 encodingutf-8 ? configuration connectionStrings add nameSuperMarketDb connectionStringData Source.;Initial CatalogSuperMarketDb;User IDsa;Password123456;MultipleActiveResultSetstrue; providerNameSystem.Data.SqlClient / /connectionStrings /configuration連接串里MultipleActiveResultSetstrue值得專門說一句。WinForm 里很容易出現(xiàn)一個連接對象執(zhí)行查詢后又在同一個連接上執(zhí)行另一條命令的情況不開這個參數(shù)就會報“已有打開的與此連接相關(guān)聯(lián)的 DataReader”。對單用戶小店開它不需要付出什么代價對多人同時在線這個參數(shù)也能減少一部分連接超時的報錯。另一個參數(shù)是Connect Timeout默認 15 秒如果門店網(wǎng)絡(luò)環(huán)境不好建議顯式設(shè)為 5讓用戶快速知道連不上而不是卡住十幾秒看起來像死機。連接串的賬號不要用 sa最低權(quán)限賬號對保護數(shù)據(jù)更有用。系統(tǒng)啟動時先測一次連通性失敗就彈提示并給出“修復數(shù)據(jù)庫連接”的入口而不是在登錄界面上轉(zhuǎn)圈。3. 把登錄、商品、結(jié)算三段邏輯寫進 WinForm能直接抄的代碼與參數(shù)3.1 登錄窗口MD5 哈希 參數(shù)化查詢擋住萬能密碼和拖庫登錄是每套收銀系統(tǒng)都有的入口但也是最容易被順手寫壞的入口。常見做法是把用戶輸入的密碼直接拼進 SQL 字符串然后執(zhí)行查詢這樣遇到 OR 11這類萬能密碼查詢條件恒為真整個系統(tǒng)就被破解了。另一個常見問題是密碼明文入庫門店內(nèi)部人員順手打開表就能看到所有人的密碼隱私和安全都談不上。正確的做法是密碼存哈希值登錄時把用戶輸入的密碼做同樣的哈希再比對。以下代碼我一般放在登錄按鈕的 Click 事件里數(shù)據(jù)庫層用參數(shù)化查詢private string Md5Hash(string input) { using (var md5 System.Security.Cryptography.MD5.Create()) { byte[] bytes Encoding.UTF8.GetBytes(input); byte[] hash md5.ComputeHash(bytes); StringBuilder sb new StringBuilder(); for (int i 0; i hash.Length; i) { sb.Append(hash[i].ToString(x2)); } return sb.ToString(); } } private bool VerifyLogin(string loginName, string loginPwd) { string connStr ConfigurationManager.ConnectionStrings[SuperMarketDb].ConnectionString; string sql SELECT COUNT(1) FROM dbo.users WHERE user_nameloginName AND user_pwdloginPwd; using (SqlConnection conn new SqlConnection(connStr)) using (SqlCommand cmd new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue(loginName, loginName); cmd.Parameters.AddWithValue(loginPwd, Md5Hash(loginPwd)); conn.Open(); return (int)cmd.ExecuteScalar() 0; } }代碼里有兩個關(guān)鍵點。一是所有用戶輸入都走AddWithValue參數(shù)化SQL 引擎會把輸入當作字面量而不是可執(zhí)行代碼萬能密碼就沒用了。二是密碼先做 MD5 再比較數(shù)據(jù)庫里即使被拖走也只拿到一串哈希。需要說明的是 MD5 用在這里并不是密碼學上的最優(yōu)方案但超市這類本地系統(tǒng)它的成本最低。你要更穩(wěn)妥可以改成 SHA256替換哈希函數(shù)時注意把循環(huán)里的MD5.Create()換成SHA256.Create()其余邏輯不動。另外AddWithValue在 SQL Server 里對NVARCHAR字段偶爾會引發(fā)隱式轉(zhuǎn)換導致索引失效更嚴謹?shù)淖龇ㄊ菍慶md.Parameters.Add(loginName, SqlDbType.NVarChar, 50).Value loginName;登錄表數(shù)據(jù)量不大影響可以忽略。登錄成功后把用戶 ID 和用戶名存到一個靜態(tài)類里后續(xù)所有窗口都能取到。還要記錄登錄時間方便后面做交接班日志。3.2 商品管理DataGridView 綁定數(shù)據(jù)表搜索用 LIKE 參數(shù)化商品管理的核心界面是 DataGridView 加一個搜索框。很多人在 TextChanged 事件里每次敲一個字母就去數(shù)據(jù)庫查一次數(shù)據(jù)量小感覺不到商品幾千條后開始卡頓。常見做法是加載一次商品表到 DataTable然后作為 DataGridView 的數(shù)據(jù)源本地做過濾。單品數(shù)量在五千以內(nèi)的超市這種方式足夠流暢。加載代碼可以復用同一段邏輯以減少重復。private DataTable productTable; private void LoadProducts() { string connStr ConfigurationManager.ConnectionStrings[SuperMarketDb].ConnectionString; string sql SELECT product_id, product_name, spec, unit, stock_qty, sale_price, warn_qty FROM dbo.products ORDER BY product_id; using (SqlConnection conn new SqlConnection(connStr)) using (SqlDataAdapter adapter new SqlDataAdapter(sql, conn)) { productTable new DataTable(); adapter.Fill(productTable); dataGridView1.DataSource productTable; } } private void FilterProducts(string keyword) { if (productTable null) return; DataView dv productTable.DefaultView; if (string.IsNullOrWhiteSpace(keyword)) { dv.RowFilter null; } else { dv.RowFilter string.Format(product_name LIKE %{0}% OR product_id LIKE %{0}%, keyword.Replace(, )); } }這種過濾方式完全走內(nèi)存比每次敲鍵盤都查數(shù)據(jù)庫快幾個數(shù)量級。但這里有個容易翻車的細節(jié)RowFilter使用的是 DataTable 的表達式語法如果搜索詞里包含單引號會直接把過濾表達式搞壞所以要先把單引號替換成雙引號上面代碼里Replace(, )就是專門做這個的。從幾百條商品里過濾出一個中文關(guān)鍵字對 DataGridView 來說已經(jīng)足夠不必上后臺線程。DataGridView 相關(guān)的參數(shù)還有一個常被忽視的如果 DataGridView 只是展示不打算在線編輯一定要把ReadOnly設(shè)為true把SelectionMode設(shè)為FullRowSelect否則用戶雙擊單元格就能改數(shù)據(jù)誤操作后庫存就悄悄變了。需要編輯價格和庫存時單獨彈出一個編輯窗口保存時再寫數(shù)據(jù)庫這樣每一步操作都有明確的意圖。3.3 結(jié)算按鈕事務(wù)包裹訂單與扣庫存避免月底對賬翻車結(jié)算是整個收銀系統(tǒng)里風險最高的一段邏輯。新手最容易犯的錯誤是先把訂單主表插進去再插明細最后扣庫存每一步獨立提交。任何一個環(huán)節(jié)失敗數(shù)據(jù)庫中就會出現(xiàn)一張缺明細的訂單或者庫存扣了但訂單沒生成月底對賬時怎么都對不上。正確做法是把這幾步包在同一個數(shù)據(jù)庫事務(wù)里要么全部成功要么全部回滾。我一般會先檢查庫存夠不夠再插入訂單頭、訂單明細最后扣減庫存。using (SqlConnection conn new SqlConnection(connStr)) { conn.Open(); using (SqlTransaction tran conn.BeginTransaction()) { try { // 檢查庫存 string checkSql SELECT stock_qty FROM dbo.products WITH(UPDLOCK, ROWLOCK) WHERE product_idpid; using (SqlCommand cmd new SqlCommand(checkSql, conn, tran)) { cmd.Parameters.AddWithValue(pid, productId); int stock (int)cmd.ExecuteScalar(); if (stock qty) throw new Exception(商品[ productName ]庫存不足); } // 插入訂單主表 string headerSql INSERT INTO dbo.invoice_header (invoice_no, user_id, total_amt, pay_amt, pay_type) VALUES (invoiceNo, userId, totalAmt, payAmt, payType); // 省略 SqlCommand 參數(shù)賦值細節(jié) // 插入訂單明細表循環(huán)商品列表 // 逐條 INSERT 或使用 SqlBulkCopy // 扣減庫存 string deductSql UPDATE dbo.products SET stock_qty stock_qty - qty WHERE product_idpid; // 省略 SqlCommand 參數(shù)賦值細節(jié) tran.Commit(); } catch { tran.Rollback(); throw; } } }這段邏輯里有兩個參數(shù)值得解釋。第一個是查詢庫存時用了WITH(UPDLOCK, ROWLOCK)鎖提示作用是在事務(wù)里鎖定這一行防止另一臺收銀機同時賣同一件商品時讀出舊庫存造成超賣。單機門店感覺不到它的存在兩臺收銀機同時運行時這個提示能避免庫存變成負數(shù)。第二個是扣庫存的 SQL 用了stock_qty stock_qty - qty而不是先讀出值再減這一步要查的舊值由數(shù)據(jù)庫自己維護可以擋住大部分并發(fā)沖突。如果用了SqlBulkCopy批量寫明細注意事務(wù)必須傳給SqlBulkCopy的Transaction屬性否則批量寫入不受當前事務(wù)控制一旦后面扣庫存失敗明細已經(jīng)持久化就失去了事務(wù)的意義。找零計算不要用 double 或 float用decimal。浮點數(shù)的二進制表示會讓 0.1 加 0.2 不等于 0.3 這類問題出現(xiàn)在找零里賬目會差到以分為單位的細節(jié)上日結(jié)時想查查不出來。整單金額、實收金額、找零金額一律用 decimal控件上輸入的字符串用decimal.TryParse轉(zhuǎn)換轉(zhuǎn)換失敗就提示重新輸入不強行解析。4. SQL 文件怎么組織建庫、存儲過程、初始化數(shù)據(jù)三件套4.1 建庫建表腳本字符集與約束一次寫對“源碼sql文件”里的 SQL 文件不是隨手導出的而是要讓拿源碼的人第一次就能在空數(shù)據(jù)庫上跑通。一套合格的 SQL 文件應(yīng)該按照固定順序排列建庫、建表、建視圖、建存儲過程、插入初始化數(shù)據(jù)。很多人拿到 sql 文件后直接全選執(zhí)行結(jié)果因為表之間外鍵依賴順序錯亂而報錯就是因為沒有組織好腳本順序。建庫語句寫在最前面表結(jié)構(gòu)按依賴順序從主表到子表排列先建不依賴別的表的表再建有外鍵的表。下面是一個基礎(chǔ)的商品表腳本示例里面把約束都寫清楚了CREATE TABLE dbo.products ( product_id INT IDENTITY(1,1) NOT NULL, product_code VARCHAR(20) NOT NULL, -- 商品條碼掃的就是它 product_name NVARCHAR(120) NOT NULL, spec NVARCHAR(50) NULL, -- 規(guī)格如500g/包 unit NVARCHAR(10) NOT NULL DEFAULT N個, stock_qty DECIMAL(10,2) NOT NULL DEFAULT 0, warn_qty DECIMAL(10,2) NOT NULL DEFAULT 10, -- 庫存預警線 sale_price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1, -- 1在售 0停售 CONSTRAINT pk_products PRIMARY KEY (product_id), CONSTRAINT uq_product_code UNIQUE (product_code) );字段類型里有幾個關(guān)鍵點。product_code用VARCHAR而不是NVARCHAR商品條碼和后臺條碼本身對中文做不了什么用定長字符串空間更省。NVARCHAR(120)用于商品名稱因為要存中文。DECIMAL(10,2)用于價格和數(shù)量不是 float。status字段用TINYINT而不是直接用 BIT方便以后擴展狀態(tài)位比如從在售到停售再到清倉。每張表都加了主鍵商品表額外做了唯一約束防止重復條碼進系統(tǒng)。執(zhí)行建表腳本時如果已經(jīng)存在同名表SQL Server 會報錯可以在腳本開頭加IF OBJECT_ID(dbo.products, U) IS NOT NULL DROP TABLE dbo.products;這樣的判斷讓腳本具備重復執(zhí)行的能力。4.2 統(tǒng)計與預警存儲過程銷售額按日匯總、庫存低于閾值彈提醒報表功能在 WinForm 項目里通常用兩條路實現(xiàn)一條是前端拼接 SQL 查詢后填 DataGridView另一條是提前建好視圖和存儲過程前端只調(diào)用。小店系統(tǒng)沒有復雜到必須上 OLAP但把統(tǒng)計邏輯放進存儲過程有一個明顯的好處換一個前端界面統(tǒng)計口徑不用重寫。我一般至少建兩個存儲過程日銷售匯總和庫存預警查詢。日銷售匯總 stored procedure 核心邏輯是按支付類型分組求銷售額同時把現(xiàn)金、微信、支付寶分開看CREATE PROCEDURE dbo.usp_DailySalesReport businessDate DATETIME AS BEGIN SET NOCOUNT ON; SELECT pay_type, COUNT(1) AS order_count, SUM(total_amt) AS sale_total, SUM(pay_amt - total_amt) AS discount_total FROM dbo.invoice_header WHERE CONVERT(DATE, create_time) CONVERT(DATE, businessDate) GROUP BY pay_type; END這里CONVERT(DATE, create_time)的作用是忽略時間部分只按天對比。參數(shù)businessDate由前端傳入日期最好在傳入時就固定為當天的零點而不是傳DateTime.Now因為報表的“業(yè)務(wù)日期”和“實際運行日期”不同晚班單據(jù)可能跨到第二天凌晨按計算機時間匯總會導致前一天少記。庫存預警存儲過程更簡單直接查出庫存低于預警線的商品清單然后前端用 MessageBox 或者小窗口彈出來。閾值不要寫死在代碼里商品表里已經(jīng)有warn_qty字段讓每個商品可以單獨設(shè)置比如雞蛋的預警線是 50 盒洗發(fā)水可設(shè)為 5 瓶。存儲過程寫完千萬別忘了給執(zhí)行權(quán)限。很多門店電腦上 SQL Server 登錄賬號權(quán)限很小默認沒有EXECUTE權(quán)限前端調(diào)存儲過程會報“對象名無效”或權(quán)限不足別把精力花在冤枉路上。4.3 初始化數(shù)據(jù)與備份恢復第一次雙擊就能登進去SQL 文件的最后一部分是初始化數(shù)據(jù)。至少要包含一個默認管理員賬號、一個測試商品列表、一個會員示例。管理員密碼不要用明文直接預置 MD5 哈希值這樣首次登錄不用先找密碼表再改系統(tǒng)。很多分享的源碼把用戶名密碼寫在 README 里但用起來不方便別人拿到后沒有善后可能就直接帶著默認密碼上線風險太高。我在編寫初始化腳本時會往用戶表里插一個admin賬號密碼哈希值是e10adc3949ba59abbe56e057f20f883e也就是 123456 的 MD5首次登錄后強制改密。初始化商品數(shù)據(jù)可以做成 INSERT 一段幾十條記錄覆蓋飲料、零食、日用、生鮮幾類典型商品條碼用真實超市常見碼模擬。如果你要部署到自己的門店不要直接用這些演示數(shù)據(jù)要把商品檔案重新導入否則收銀臺上掃碼槍掃出來的價格是別人的。SQL 文件里還要帶上備份恢復說明至少給出一個標準備份腳本BACKUP DATABASE SuperMarketDb TO DISK ND:\backup\SuperMarketDb_202501.bak WITH INIT, COMPRESSION;恢復時的腳本也要附上但需要注意恢復前要強制斷開現(xiàn)有連接ALTER DATABASE SuperMarketDb SET SINGLE_USER WITH ROLLBACK IMMEDIATE; RESTORE DATABASE SuperMarketDb FROM DISK ND:\backup\SuperMarketDb_202501.bak WITH REPLACE; ALTER DATABASE SuperMarketDb SET MULTI_USER;備份文件命名里帶日期每天凌晨用 Windows 計劃任務(wù)跑一次比任何高深的備份策略都實在。小店不會有人天天記得手工備份自動化是唯一可靠的路。5. WinForm 收銀系統(tǒng)避坑手冊五條踩坑記錄現(xiàn)象原因解決一條條對5.1 界面假死和跨線程崩潰Timer 刷新和 UI 線程打架現(xiàn)象系統(tǒng)跑一會兒就卡住尤其在高峰期點擊按鈕沒反應(yīng)過幾秒又活過來。如果讓后臺線程直接操作控件程序直接拋異常崩掉。原因WinForm 的 UI 控件只能在創(chuàng)建它的主線程里操作。很多人在代碼里開了后臺線程查庫存查詢完成后直接執(zhí)行l(wèi)abel1.Text ....運行時遇到跨線程操作就會拋InvalidOperationException。另一方面如果所有查詢都堆在主線程執(zhí)行數(shù)據(jù)庫響應(yīng)慢時界面就假死看起來像整個程序停擺。解決跨線程更新控件用Control.BeginInvoke把操作調(diào)度回 UI 線程不要用Control.CheckForIllegalCrossThreadCalls false壓制報錯那是把隱患壓下去后面會讓數(shù)據(jù)不同步得更邪門。后臺線程只負責取數(shù)據(jù)拿到結(jié)果后丟回 UI 線程更新。如果是主線程等待數(shù)據(jù)庫考慮把查詢封裝成異步方法。門店系統(tǒng)數(shù)據(jù)量不大最簡單的做法是收銀臺結(jié)算時給主界面一個“正在結(jié)算”的提示讓用戶知道系統(tǒng)在工作而不是卡死。5.2 中文亂碼SQL 文件導入后整表問號現(xiàn)象運行別人給的 sql 文件商品表里的中文變成一排問號或者導入時報“字符串或二進制數(shù)據(jù)將被截斷”。原因SQL 文件本身保存的編碼和 SQL Server 解析時使用的編碼不一致。用記事本另存為 ANSI 的腳本導入到 SQL Server 2012 以上實例中秋風掃落葉一樣把中文字符解析錯。另一個原因是 INSERT 語句里的中文字符串沒有加N前綴導致隱式轉(zhuǎn)換后亂碼。解決SQL 文件統(tǒng)一保存為帶 BOM 的 UTF-8 編碼在 SSMS 打開時選擇“Unicode UTF-8”。所有插入中文的字符串常量都寫成N中文例如INSERT INTO dbo.products (product_name) VALUES (N可口可樂)。文件已經(jīng)亂碼的只能用文本編輯器重新把內(nèi)容保存為正確編碼再執(zhí)行沒有別的后悔藥。部署到門店時建議把 SQL 文件放進源代碼目錄一起走不要從微信聊天記錄里復制微信傳輸會動文件編碼。5.3 掃碼槍輸入自動觸發(fā)按鈕焦點控制與回車攔截現(xiàn)象掃碼槍掃一個商品條碼商品沒有被添加進購物車反而彈出了登錄窗口或者把當前編輯框的內(nèi)容提交了收銀臺操作完全混亂。原因大多數(shù)掃碼槍是“鍵盤模擬器”相當于在聚焦的控件上快速輸入一串字符再敲一個回車。如果焦點剛好在“查詢”按鈕上回車就觸發(fā)了按鈕的 Click 事件。這個行為在 WinForm 里特別容易讓人一頭霧水看起來是程序亂跳其實是焦點和回車事件在作祟。解決為掃碼槍做一個專門的輸入框不讓焦點跑到其他按鈕上。在輸入框的 KeyPress 事件里判斷如果按下的是回車就取出完整條碼去查詢并添加購物車同時用e.Handled true吞掉這個回車事件。這樣掃碼槍的自動回車不會再觸發(fā)按鈕人工鍵盤在輸入框里按回車也只會添加商品。如果系統(tǒng)里有多個窗口都希望響應(yīng)掃碼把掃碼輸入的邏輯統(tǒng)一封裝到一個控件里不要在每個窗口里各寫一遍否則改一處忘一處。private void txtScan_KeyPress(object sender, KeyPressEventArgs e) { if (e.KeyChar (char)13) { string barcode txtScan.Text.Trim(); AddProductToCart(barcode); txtScan.Clear(); txtScan.Focus(); e.Handled true; // 關(guān)鍵攔截回車防止觸發(fā)按鈕 } }5.4 庫存變負數(shù)兩臺收銀機并發(fā)扣減同一件商品現(xiàn)象月底盤點發(fā)現(xiàn)庫存比賬面少了甚至出現(xiàn)負數(shù)。日志里看不到誰刪過數(shù)據(jù)數(shù)據(jù)庫也找不到異常操作。原因兩臺收銀機同時賣同一件商品時兩邊的程序都先查詢庫存查到的都是 10各自判斷庫存足夠后扣減 1結(jié)果兩次 UPDATE 后庫存變成 8實際只賣了 2 件卻扣了 2 次庫存。這種問題在單品數(shù)量少、價格高的小超市特別常見一瓶貴價酒被賣成負數(shù)。解決扣庫存的 SQL 用原子更新不再先查后改。UPDATE dbo.products SET stock_qty stock_qty - qty WHERE product_id pid AND stock_qty qty這一步如果影響行數(shù)為 0說明庫存不足或商品不存在再在事務(wù)里回滾并提示用戶。配合上一章提到的UPDLOCK鎖提示兩臺收銀機同時點擊結(jié)算時數(shù)據(jù)庫會在行級串行化處理不會再出現(xiàn)各自讀舊庫存的競態(tài)。如果你把商品表放到內(nèi)存緩存里做扣減一定要保證緩存更新和數(shù)據(jù)庫更新在同一事務(wù)里否則緩存與數(shù)據(jù)庫不一致的坑更大不建議小系統(tǒng)做這么復雜。5.5 換電腦跑不起來連接串與安裝打包的坑現(xiàn)象源碼在自己的電腦上運行正常打包安裝到門店另一臺電腦上打開就報“在與 SQL Server 建立連接時出現(xiàn)與網(wǎng)絡(luò)相關(guān)的或特定于實例的錯誤”。原因最常見的是連接串寫死了電腦名或 IP拿到新環(huán)境后數(shù)據(jù)庫實例名、賬號密碼都不一樣而代碼里后綴是寫死的.或者開發(fā)機的實例名。其次是目標機器沒裝 SQL Server 或者只裝了 Express連接串卻連接的是默認實例。還有人忘了把App.config一起發(fā)布導致新機器拿不到配置。解決連接串讀ConfigurationManager部署時直接改App.config文件不用重新編譯。打包工具我一般用 Inno Setup比 VS 自帶的 InstallShield 直觀一些主程序、運行庫、配置文件一起打包。門店電腦必須有 SQL Server 實例裝 Express 也可以用但連接串要寫成Data Source.\\SQLEXPRESS并且配好賬號。如果你用 ClickOnce 發(fā)布注意App.config會被轉(zhuǎn)換調(diào)試好的連接串可能被覆蓋得在發(fā)布選項里排除配置文件或者部署后重新設(shè)置。一個更省心的做法是程序啟動時檢測數(shù)據(jù)庫連接失敗則彈出一個小窗口讓維護人員填服務(wù)器地址、賬號、密碼自動寫回App.config。這樣新門店部署時就不需要任何開發(fā)者到場多出一段二十行的配置對話框能省掉不知道多少個電話和遠程。6. 今晚就能做的性能驗證把收銀臺反應(yīng)時間壓到一百毫秒以內(nèi)收銀臺體驗好壞核心指標是掃一個商品到購物車多了一行這個過程用戶能不能感到“秒開”。如果掃完條碼還要轉(zhuǎn)圈等一秒高峰期排隊的顧客就能感受到這家店系統(tǒng)很慢負面影響直接反應(yīng)在門店口碑上。這套 WinForm 系統(tǒng)性能瓶頸不在 WinForm而在數(shù)據(jù)庫訪問頻率。我建議你今晚做三個測試不需要改架構(gòu)只需要在現(xiàn)有代碼上加一層優(yōu)化。第一個測試是商品緩存。收銀臺掃商品時程序每次去數(shù)據(jù)庫按條碼查一條商品這是最常見的慢點。幾百毫秒的數(shù)據(jù)庫往返加上網(wǎng)絡(luò)延遲疊加每個商品查一次結(jié)賬十條商品的訂單就多出好幾秒。改法是在程序啟動時把商品表加載進一個Dictionarystring, ProductCacheItem鍵是條碼掃一個取一個完全不打數(shù)據(jù)庫。緩存里的stock_qty只在結(jié)賬扣庫存后才更新同時后臺每隔五分鐘刷新一次緩存。第二個測試是 DataGridView 虛擬模式。商品多到萬級時直接綁定 DataTable 滾動會肉眼可見地卡。把 DataGridView 的VirtualMode設(shè)為 true自己實現(xiàn)CellValueNeeded事件只提供當前屏幕需要顯示的幾十行滾動極流暢。虛擬模式的代價是失去自動排序和自動編輯但收銀系統(tǒng)根本不依賴這些功能適合純展示場景。第三個測試是批量寫入。一個訂單十條明細如果用十個 INSERT 語句逐條執(zhí)行每條都有連接往返放本地還好走網(wǎng)絡(luò)就連累結(jié)賬速度。改成SqlBulkCopy一次性把明細表寫入數(shù)據(jù)庫或者用表值參數(shù)傳入存儲過程能把這十次往返變成一次。SqlBulkCopy 要記得把事務(wù)對象傳進去否則訂單主表成功明細表失敗數(shù)據(jù)完整性直接破防。我以前接手過一家門店的收銀系統(tǒng)結(jié)賬高峰期顧客排了四條隊還是慢查了半天發(fā)現(xiàn)他們在明細循環(huán)里每次都寫日志文件日志寫盤和數(shù)據(jù)庫查詢串行執(zhí)行把整個收銀速度拖到了三秒一單。去掉日志同步寫加一個商品緩存整體響應(yīng)時間壓到一百毫秒以內(nèi)。那次之后我養(yǎng)成了一個習慣任何收銀系統(tǒng)優(yōu)化第一件事永遠是看數(shù)據(jù)庫請求次數(shù)而不是糾結(jié)界面美觀。先把掃商品不查庫、結(jié)算只寫一次庫這兩件事做到收銀臺就基本不會再被吐槽慢。希望這些經(jīng)驗和踩過坑的參數(shù)能幫到你照著這個方向調(diào)完你再回來看這套 WinForm 項目就會覺得處處都能解釋得通了。本文還有配套的精品資源點擊獲取