企业官网建设流程全解析

简介：一份用C#语言编写的基于短信猫硬件的短信群发完整源码，面向需要快速搭建批量短信业务的.NET开发者或企业信息化项目人员，解决通过GSM模块控制短信猫进行批量发送、模板管理与状态跟踪的实际问题。压缩包内共114个文件，包含38个C#源文件用于实现业务逻辑与窗体交互，17个resx与resources资源文件配合14个gif和6个jpg提供界面素材，7个dll与3个exe保证依赖库和可运行程序齐备，并附Access数据库、解决方案及文档，整体仅721KB，结构清晰，可直接编译运行。目前已有120人学习。源码覆盖串口通信、AT指令对接短信猫、多线程并发群发、号码与短信模板管理、发送状态跟踪等关键环节，同时展示了企业级WinForm程序的窗体设计、分层架构、数据库操作及异常处理方式，适合作为C#通信编程、GSM协议应用和桌面开发实战的参考项目。

1. C#短信群发源码：用本地短信猫把发送成本打成零

群里做运营的朋友常抱怨：云短信平台一发活动通知，先审核模板，再按条计费，几千条下去运营成本直接超支。某次帮一家小公司处理客户回访需求，发现他们手里有一堆号码，但每月短信费高得离谱，还经常因为模板审核被卡在最后一刻。换成本地短信猫方案之后，问题顺利解决了：一台USB短信猫插上SIM卡，电脑程序通过串口直接下AT指令，短信走运营商网络发出，不依赖任何云接口。这份C#短信群发源码就是这类方案里能用的一版，技术栈围绕串口通信、PDU中文编码和发送队列展开，能批量发、能重试、能记日志。

项目适合谁，一句话能说清：手里已有短信猫硬件、想省掉云短信费用、又希望代码在自己内网跑的C#开发者，或者小团队里的运维兼开发。源码把短信发送链路完整串了起来，对只想跑通的人来说，改几个参数就能用；对想做二次开发的人来说，串口层、编码层、队列层分得比较清楚，动手改不会牵一发动全身。

接下来按我自己拆解这类工程的习惯，从整体架构到核心代码，再到联调验证和避坑，一条线讲完。最后补几个二次开发改造思路，算是把这套源码真正变成自己的工具。

2. 整体架构：串口、AT指令、发送队列三者怎么配合

2.1 技术选型：为什么用C#直接控制串口而不是接第三方SDK

现在做短信群发，大多数人的第一反应是接云短信平台HTTP接口。短信猫方案最大的不可替代之处在于：短信内容不走公网，不依赖第三方服务商的模板审核，只要SIM卡能发短信，程序就能发，按条计费变成只按卡费计。对部署在内网、对数据隐私有要求的场景，这种离线方案比云接口稳得多。

这套源码用的常见组合是C# WinForm程序加System.IO.Ports.SerialPort。短信猫插上电脑后，在系统里会识别成一个COM口，程序发AT指令进去，短信猫反馈OK或者错误码。整个交互是命令-响应模式，没有复杂的协议栈，所以连PDU中文编码也直接手写，不引第三方库。这样的选型有一个明显好处：代码里每一步做了什么都能看清楚，出问题不至于对着封装好的库抓瞎。

技术栈可以整理成一张表：

2.2 源码目录结构：一个可编译工程的模块划分

拿到源码包后，第一件事不是找Form1.cs，而是先看目录结构。这个项目的组织方式是标准的分层：

SmsSender/ ├── SmsSender.sln ├── SmsSender/ │ ├── App.config │ ├── Program.cs │ ├── MainForm.cs # 主界面，加载联系人、启动发送 │ ├── MainForm.Designer.cs │ ├── Core/ │ │ ├── ModemManager.cs # 串口初始化、AT指令交互 │ │ ├── PduEncoder.cs # PDU编码，中文转UCS2十六进制 │ │ ├── SmsQueue.cs # 并发队列，后台发送线程 │ │ └── SmsLogger.cs # 日志写入 │ └── Models/ │ ├── SmsMessage.cs # 短信实体：手机号、内容、重试次数 │ └── SendResult.cs # 发送结果记录

Core目录是整个项目的核心，ModemManager负责和短信猫说话，PduEncoder负责把中文内容变成短信猫能理解的PDU格式，SmsQueue负责排队和重试。Models里只是两个数据类。界面层很薄，只做按钮触发和进度显示，真正的业务逻辑全部下沉到了Core，这种拆法方便以后换成控制台程序或者Windows服务，不用动核心代码。

2.3 短信群发主流程：从号码加载到SIM卡发出要过几道关

一条短信从界面上点击发送到真正从天线出去，中间有六步：

1. 加载联系人列表，校验手机号格式，过滤空号和非11位号码
2. 把短信内容按PDU编码规则转成十六进制字符串
3. 从并发队列里取出一条待发送短信
4. 通过串口向短信猫发送AT指令，进入PDU发送模式
5. 发送PDU数据并以Ctrl+Z结束，等待短信猫返回+CMGS响应
6. 记录发送结果，失败则判断是否超过最大重试次数

这个流程看起来简单，实际运行中问题都出在第4、5步。短信猫不是网络设备，没有缓冲区队列，多条AT指令同时发过去它会直接丢或者卡死，所以必须保证同一时刻只有一个线程在操作串口。这也是为什么队列不能省：群发几百条时，如果界面线程直接循环发送，界面会假死，串口还会因为并发写入乱套。

3. 核心代码拆解：AT指令通道、PDU编码、发送队列一次讲清

3.1 串口初始化与AT指令通道：ModemManager怎么和短信猫对话

ModemManager负责打开串口、发送指令、等待响应。常见的短信猫默认波特率是9600，数据位8，停止位1，无校验。初始化代码很直接：

public class ModemManager : IDisposable { private SerialPort _port; public bool Connect(string portName, int baudRate = 9600) { _port = new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One) { ReadTimeout = 1000, WriteTimeout = 1000 }; try { _port.Open(); // 发一条AT指令探测短信猫是否在线，返回OK表示设备就绪 string response = SendCommand("AT\r"); return response.Contains("OK"); } catch (UnauthorizedAccessException) { // 串口被其他程序占用时，SerialPort.Open会抛这个异常 return false; } catch (TimeoutException) { return false; } } public string SendCommand(string command) { _port.Write(command); Thread.Sleep(300); return _port.ReadExisting(); } }

逻辑说明：SendCommand先写指令，再等300毫秒让短信猫响应，最后把串口缓冲区里的数据全部读出来。这里用ReadExisting而不是ReadLine，是因为不同品牌短信猫在AT响应末尾的换行符并不统一，有的发\r\n，有的只有一个\r，ReadLine有时候会把尾巴截掉，导致明明返回了OK却没识别出来。

参数说明：ReadTimeout和WriteTimeout设置为1000毫秒是保守值，如果短信猫模块响应慢，这个值会触发超时异常导致误判设备离线。我一般会写到1500毫秒，给老设备留点余量。端口名从界面配置里读，形如COM3，不要写死。

3.2 PDU编码：中文短信不乱码的关键实现

短信猫有两种工作模式：文本模式（AT+CMGF=1）和PDU模式（AT+CMGF=0）。文本模式只能发英文和数字，中文会变成问号。发中文短信必须用PDU模式，并且把内容转成UCS2编码。这段是全网找得到源码里最容易抄错的部分，我拆开讲。

public static class PduEncoder { // 号码半字节反转：8613800755500 -> 68310870550F0 private static string EncodeNumber(string number) { if (number.StartsWith("+")) { number = number.Substring(1); } StringBuilder sb = new StringBuilder(); for (int i = 0; i < number.Length; i += 2) { int first = number[i] - '0'; int second = (i + 1 < number.Length) ? number[i + 1] - '0' : 15; sb.AppendFormat("{0:X1}{1:X1}", second, first); } return sb.ToString(); } // 构建短信中心号字段 private static string BuildSmscPart(string smscNumber) { string encoded = EncodeNumber(smscNumber); string content = "91" + encoded; int lenBytes = 1 + encoded.Length / 2; return lenBytes.ToString("X2") + content; } // 构建目标手机号字段 private static string BuildTargetAddress(string phone) { string encoded = EncodeNumber(phone); int nibbleLen = phone.Length; return nibbleLen.ToString("X2") + "91" + encoded; } // 中文内容转UCS2十六进制 private static string ToUcs2Hex(string text) { byte[] bytes = Encoding.BigEndianUnicode.GetBytes(text); StringBuilder sb = new StringBuilder(); foreach (byte b in bytes) { sb.Append(b.ToString("X2")); } return sb.ToString(); } public static string BuildSubmitPdu(string smscNumber, string phone, string text) { string smscPart = BuildSmscPart(smscNumber); string targetPart = BuildTargetAddress(phone); string content = ToUcs2Hex(text); string tpduFirstPart = "1100" + targetPart + "000800"; // 用户数据长度占1个字节，所以TPDU总字节数要先加上1 int tpduLen = tpduFirstPart.Length / 2 + 1 + content.Length / 2; return smscPart + tpduFirstPart + content.Length.ToString("X2") + content; } }

逻辑说明：BuildSubmitPdu返回的是一整条十六进制PDU，前半部分是短信中心号，后半部分是TPDU。短信中心号字段先逆序排列，再在前面加91表示国际号码类型；目标手机号只写本地11位，长度字段填半字节数而不是字节数，这是最容易写错的地方。最后的内容部分用BigEndianUnicode把中文转成UCS2，每个汉字占两个字节，十六进制后变成4个字符。

参数说明：smscNumber是短信中心号，一般就是+8613800后跟四位地区码，可以在手机上插卡后通过AT+CNUM或问运营商查到。发送时AT+CMGS的参数是TPDU字节数，也就是BuildSubmitPdu返回字符串去掉smscPart之后那一段的长度，按字节计，不是按字符计。这块代码我当初也是对着协议文档一行行调试出来的，别觉得长，每部分都有对应含义。

3.3 发送队列：群发几百条时怎么保证线程安全

直接一个for循环发几百条短信，界面会卡死，串口数据还会互相覆盖。这个项目里的SmsQueue用了BlockingCollection，一个后台线程专门消费队列里的短信，UI线程只负责往队列里塞数据：

public class SmsQueue { private BlockingCollection<SmsMessage> _queue = new BlockingCollection<SmsMessage>(); private CancellationTokenSource _cts = new CancellationTokenSource(); private readonly ModemManager _modem; private readonly int _retryCount; public SmsQueue(ModemManager modem, int retryCount = 3) { _modem = modem; _retryCount = retryCount; } public void Enqueue(SmsMessage message) { _queue.Add(message); } public void Start(CancellationToken? token = null) { Task.Factory.StartNew(() => ProcessLoop(_cts.Token), TaskCreationOptions.LongRunning); } private void ProcessLoop(CancellationToken ct) { foreach (var message in _queue.GetConsumingEnumerable(ct)) { int currentRetry = 0; bool success = false; while (currentRetry <= _retryCount && !success) { success = SendOne(message); currentRetry++; } SmsLogger.Log(message.Phone, success, currentRetry); } } private bool SendOne(SmsMessage message) { string pdu = PduEncoder.BuildSubmitPdu( SmsConfig.SmscNumber, message.Phone, message.Content); // 通知短信猫进入PDU模式，然后发送TPDU return _modem.SendWithPdu(pdu); } }

逻辑说明：ProcessLoop用GetConsumingEnumerable从队列里拿消息，队列为空时这个调用会阻塞，不会空转CPU。每条短信最多重试三次，三次都失败就写进日志，不影响后续消息发送。这里最关键的是Start方法用LongRunning方式开独立线程，避免线程池线程被长时间占用后影响程序其他任务。

有一个细节值得注意：BlockingCollection默认走内部ConcurrentQueue，出队顺序是先进先出。如果业务上有VIP号码优先发送的需求，需要把默认集合换成ConcurrentStack或者优先级队列，这里没做，按顺序处理就行。

3.4 PDU发送细节：等待大于号再发内容

ModemManager的SendWithPdu是发短信的完整动作，这里单独拿出来说，因为很多人倒在前半段：

public bool SendWithPdu(string fullPdu) { // 从PDU里分离短信中心号和TPDU int smscLen = Convert.ToInt32(fullPdu.Substring(0, 2), 16); string tpdu = fullPdu.Substring(2 + smscLen * 2); // 发AT+CMGS指令，参数是TPDU的字节数 string command = "AT+CMGS=" + (tpdu.Length / 2).ToString() + "\r"; _port.Write(command); // 等待短信猫返回 ">" 提示符，表示可以输入PDU数据 string expect = ReadUntil(">"); if (!expect.Contains(">")) { return false; } // 将PDU十六进制转成字节数组，写入串口，最后跟0x1A表示结束 byte[] pduBytes = FromHex(tpdu); _port.Write(pduBytes, 0, pduBytes.Length); _port.Write(new byte[] { 0x1A }, 0, 1); string response = ReadUntil("OK"); return response.Contains("OK"); }

逻辑说明：发送PDU短信不是把整串十六进制文本塞给短信猫，而是先发AT+CMGS，等短信猫输出了大于号提示符，才允许输入PDU字节，最后必须追加十六进制值1A（键盘上的Ctrl+Z）表示消息结束。注意TPDU字节数的计算：smscLen是短信中心号字段的字节数，所以要先把fullPdu开头的长度字段和短信中心号内容去掉，剩下的才是TPDU。

这里的坑在于ReadUntil函数的实现。短信猫在收到AT+CMGS后可能会先回显命令本身，再输出大于号。如果代码只读一次串口缓冲区，很可能读到的是空字符串。常见做法是循环读取直到缓冲区包含>字符，每次读之间有20到50毫秒的间隔，不要用Sleep(1000)干等，那会把发送速度拖垮，几百条短信会非常慢。

4. 运行手册：把源码变成能群发的程序

4.1 环境准备与编译

开发环境用Visual Studio 2022即可，工程是常见的.NET WinForm项目。打开SmsSender.sln后如果编译报错，第一时间检查目标框架和引用项。这个源码的串口通信依赖System.IO.Ports程序集，如果是.NET Framework工程，这个命名空间默认在框架里；如果是.NET 6以上的新式工程，需要在NuGet里补一个System.IO.Ports包。

编译过程中最常见的错误就是SerialPort类型找不到，解决办法是在NuGet包管理器里搜索System.IO.Ports，安装最新稳定版。装完之后看到引用列表里多出System.IO.Ports，重新生成就能通过。整个项目没有复杂的前置依赖，不装数据库，不启动服务，一台装了Windows的普通电脑就能跑。

4.2 电脑识别短信猫和COM口号确认

把短信猫插上电脑的USB口，先安装厂商提供的驱动程序。驱动装好之后，打开设备管理器，找到端口(COM和LPT)这一项，里面会出现一个USB-SERIAL CH340之类的设备，后面括号里写着COM3这样的端口号。这个COM口号就是程序里要填的串口号。

这里要注意一个坑：同一台电脑插两个同样的短信猫，设备管理器会把它们的COM号乱序分配，可能是COM3和COM6，没有规律。所以每次换USB口，COM号都可能变。运行程序前先看一眼设备管理器里的实际值，别拿上一次的配置直接发，发送过程中才发现没连上就晚了。

4.3 修改配置文件：串口号、短信中心号、重试次数

打开App.config，核心参数就三个：

<appSettings> <!-- 短信猫所在串口号，以设备管理器为准 --> <add key="SerialPort" value="COM3" /> <!-- 波特率，多数短信猫是9600，老模块也见过19200 --> <add key="BaudRate" value="9600" /> <!-- 短信中心号，格式带+号，问运营商要当地号码 --> <add key="SmscNumber" value="+8613800755500" /> <!-- 每条短信最大重试次数 --> <add key="MaxRetryCount" value="3" /> </appSettings>

参数说明：SmscNumber就是PDU编码里构建短信中心字段用的，如果不知道当地短信中心号，最简单的办法是把自己的SIM卡插到普通手机里，在手机设置的SIM卡信息里能看到，或者打运营商客服查。这个参数填错了，短信能发出去，但接收方可能收不到或者显示乱码。重试次数建议保持默认，太多会让队列越积越久，后面的短信延误加重。

4.4 联调验证：不经过界面，先手动发一条

这一步是我拆这类项目必做的事。程序跑起来之前，先手动确认短信猫工作正常，避免把问题全部归结到代码上。打开串口调试工具，选对COM口和波特率，逐条发送以下指令：

AT AT+CMGF=0 AT+CMGS=24

第一条返回OK说明串口通了；第二条表示进入PDU模式，返回值还是OK；第三条是固定命令，正确响应是短信猫输出一个换行和一个大于号。看到大于号后，粘贴一条构建好的PDU十六进制数据，再发送十六进制值1A，观察串口工具返回+CMGS:数字和OK。

如果到第三步没出现大于号，说明短信猫模块本身工作异常，或者是波特率不对，有杂乱的不可读字符。调试工具里的接收区能看到乱码就是波特率问题，切换到常见值再试。整条链路通了，再回程序里点发送按钮，成功率会高很多。

5. 避坑指南：短信猫群发最容易翻车的几个点

这一章写的是我在实际使用中翻过的车，每条都按现象、原因、解决三步讲。

5.1 中文短信发出去变成问号或乱码

现象：程序能发送，接收方收到短信，但中文全变成??或者乱码，英文和数字正常。

原因：短信猫还是用文本模式发送，AT+CMGF=1时中文无法用GSM 7bit编码表达，模块只能输出替代字符。有些老模块即使切换到PDU模式，内容编码字段写错了也会乱码。

解决：首先确保发送前执行AT+CMGF=0，其次检查PDU编码里内容编码方案字段，中文对应的是00 08而不是常见的00 01。如果是00 01，说明用的还是7bit编码，中文必然乱码。在PduEncoder里检查content前面拼接的编码字段是否固定为0008。

5.2 点发送后程序卡死，像假死一样

现象：界面无响应，串口灯不闪，关也关不掉，只能任务管理器强杀。

原因：发送逻辑直接在UI线程里跑了，串口读写是阻塞操作，ReadTimeout没有触发时线程就卡在串口读取上。多数是发送代码里用了while循环读串口，但短信猫没回复，死等导致假死。

解决：第一，主流程必须走队列加后台线程，UI线程只做队列的Enqueue；第二，所有串口读取都设置ReadTimeout，并且循环里对超时要抛异常处理；第三，如果需要取消发送，在ProcessLoop里加入CancellationToken检查，不然任务开始后没办法中断。

5.3 短信发了一部分就停了，日志里全是超时

现象：前几十条发送正常，后面连续超时，短猫模块指示灯异常或干脆没反应。

原因：短信猫模块连续工作会发热，尤其劣质USB供电模块，长时间高负载会掉电或者死机。另一个常见原因是发送间隔太短，短信猫来不及处理完一条指令就收到下一条。

解决：在SendOne方法成功或者失败之后加Thread.Sleep(200)，给模块喘息时间。如果条件允许，用带独立电源的短信猫，不要用USB口直接供电，台式机前置USB口供电不稳更容易触发这个问题。

5.4 串口被占用，程序启动报UnauthorizedAccessException

现象：程序启动连接串口时直接报串口被占用，先开的串口调试工具没关，或者另一个程序实例还在后台跑。

原因：Windows下串口是独享设备，同时只能有一个进程打开同一串口号。程序异常退出后串口没有释放，也会出现这个现象。

解决：启动时把连接失败原因弹出来提示用户关闭占用程序。代码里可以做一层互斥检测，比如程序只允许单实例运行，同时在退出时确保调用SerialPort.Dispose。开发调试时记住一个习惯：改完代码重新编译前，先关掉上次运行残留的进程，避免串口没释放导致新进程连不上。

5.5 长短信超长被拆成多条，费用翻倍

现象：发送内容超过70个汉字，短信猫把一条内容拆成多条发送，接收方收到好几条短信，费用按多条计算。

原因：PDU模式下UCS2编码每条短信最多140字节，每个汉字占2字节，所以上限是70个汉字。超过之后模块会按长短信拆分，计费按拆分后的条数算。

解决：发送前在入队前判断内容长度，超过70个汉字就主动提示用户拆分，不要静默给用户发多条。如果确实需要长短信，可以查看短信猫是否支持拼接长短信的协议（UDH），但多数GSM模块默认不支持，建议内容控制在70字以内。

6. 二次开发：给源码加上Excel导入、定时发送与失败号码导出

6.1 改造一：批量联系人导入从Excel来

现有源码里联系人大概率是手工粘贴进文本框。实际使用场景离不开Excel，最简单的方式是加一个导入按钮，用ExcelDataReader读取第一列手机号，第二列客户称呼，然后拼成短信内容入队：

using ExcelDataReader; public List<SmsMessage> ReadContacts(string filePath) { using var stream = File.Open(filePath, FileMode.Open, FileAccess.Read); using var reader = ExcelReaderFactory.CreateReader(stream); var messages = new List<SmsMessage>(); reader.Read(); // 跳过表头 while (reader.Read()) { string phone = reader.GetString(0)?.Trim(); string name = reader.GetString(1)?.Trim(); if (string.IsNullOrEmpty(phone)) continue; if (phone.Length != 11 || !phone.StartsWith("1")) continue; messages.Add(new SmsMessage { Phone = phone, Content = $"{name}您好，您在我司的订单已发出，请留意查收。" }); } return messages; }

逻辑说明：读取Excel时用流式读取而不是一次性Load，几百行没问题，几万行也不会吃太多内存。手机号校验这里只做了基础判断，如果要更严，可以用正则进一步核对第二位是否在3到9之间。新手容易踩的坑是Excel文件里号码被识别成了数字，读完发现后面没小数位，需要在校验前转成字符串再Trim掉多余的.0。

参数说明：ExcelDataReader是非官方库，在NuGet里选择稳定版本，注意它读取.xlsx和.xls的方式一致，但老版本.xls需要额外引入ExcelDataReader.DataSet扩展包，按项目实际需求引入。

6.2 改造二：定时任务按计划发送

群发短信常见场景是定时发送，比如晚上八点统一发提醒。给WinForm加定时功能，不用上复杂的任务调度框架，一个Timer就够用：

private Timer _sendTimer; private void InitTimer() { _sendTimer = new Timer(); _sendTimer.Interval = 1000; // 每秒检查一次 _sendTimer.Tick += (s, e) => CheckSchedule(); _sendTimer.Start(); } private DateTime _scheduledTime; private bool _triggered; private void CheckSchedule() { if (_triggered) return; if (DateTime.Now >= _scheduledTime) { _triggered = true; StartSending(); } }

逻辑说明：定时逻辑最怕重复触发，所以加了一个_triggered标记，触发一次后不再进入StartSending。定时时间可以配置到App.config里，也可以做成界面上DateTimePicker控件让用户选。如果需求是每天固定时间，那就在CheckSchedule里换成对时分秒的比较，每天触发一次。

更复杂的场景比如每月1日发账单提醒，我会把Timer回调里改成检查当天日期和上一次执行记录，把“是否执行过”落库或者落到配置文件，避免程序重启后再触发一次重复短信。这部分不复杂，但是细节决定了会不会被客户投诉。

6.3 改造三：发送失败号码单独导出

SmsLogger现在只写文本日志，但是运营人员需要的是“哪些号码失败了”的清单，方便二次补发。最简单的方式是打开发送完成之后，把失败列表导出到CSV：

public void ExportFailedNumbers(List<SendResult> results, string path) { var failed = results .Where(r => !r.Success) .Select(r => $"{r.Phone},{r.ErrorMessage}") .ToList(); File.WriteAllLines(path, failed, Encoding.UTF8); }

逻辑说明：导出CSV用UTF-8编码，Excel打开中文才不会乱码。这里的SendResult集合可以在SmsQueue里累积，队列处理完一条就追加一条，发送任务结束时把失败列表写出去。很多项目会在这个基础上加一个补发按钮，把导出的CSV重新导入队列，相当于一个闭环。

6.4 改造后怎么验证链路没有改坏

二次开发最常见的翻车点是改完一处，另外一处悄悄坏了。我的习惯是每次改造后强制走一遍三层验证：先做串口连通性测试，发送AT等待OK；再发一条PDU短信给自己手机，确认接收内容和时间正常；最后批量发送5条测试号码，检查日志状态码和失败重试是否按预期执行。这三步通过，再谈上百条的真正群发。

从那以后我每次换短信猫、换SIM卡、改配置参数，都强制走一遍AT连通、单条PDU、批量压测这三步自检，再从队列里发真实号码。代码里值得改的地方很多，但通信链路的稳定性永远是第一位的。希望帮到你。

本文还有配套的精品资源，点击获取