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