简介：基于C#的编组站调车系统是一份面向铁路运输信息化与C#开发学习者的完整项目资源，适合用于理解编组站调车业务流程及Windows窗体程序的设计方法。资源包含完整Visual Studio工程，共47个文件，以16个.cs源码文件为核心，涵盖窗体界面、业务逻辑与数据访问分层；另有可执行exe直接运行观察效果，txt说明文档记录操作思路，resources/resx资源文件与配置文件保证项目编译运行完整。压缩包仅221KB，轻量易用，已有122人查看学习。项目通过隐藏与显示文本框的方式模拟货车在线路间的动态跳变，直观展示了GUI控件控制与动画模拟技巧，同时涉及登录窗体、主窗体、DAL与Model分层设计，可作为综合运用集合、文件操作、事件驱动编程的练手项目。对希望掌握C#桌面应用开发、调度模拟系统设计的开发者有不错的参考价值。
1. 先说结论：基于C#的编组站调车系统，解决的是“等排路、抄车号、对不上账”三件事
编组站一个白班下来，最耗调车区长精力的往往不是调车本身，而是等排路、抄车号和对账。车还在到发线，钩计划却要靠电话跟值班员、扳道员来回确认；一钩溜放完了，现车台账能不能跟上，取决于底下人有没有记得报。基于C#的编组站调车系统，做的是把“到达—解体—编组—出发”这条主线上最磨人的三件事——钩计划、车号核对、现车账目——收进一套桌面程序里，让作业从人肉接力变成数据接力。
这套东西适合谁？还没上全套峰顶自动化系统的中小编组站、区段站，货场兼办编组的车站，以及车辆段取送车作业。这类场站不一定缺调车机，缺的是一个能记录“现在每辆车在哪条股道第几位、下一步该干什么”的电子账本。用C#落地，是因为现场跑的还是Windows，要对接的设备接口又大多是串口和DLL，这个场景本来就是C#上位机的舒适区。
2. 拆需求：编组站调车作业的主线、对象，和C#选型的三个理由
2.1 调车系统在干什么：从到达解体到出发编组的作业主线
编组站的作业主线并不复杂。一趟列车进到到发场后，先做到达确报，拿到完整的编组顺序；然后调车机把车列牵出或推上牵出线，按车辆去向把整列车切成若干组，溜放到编组场对应的股道；等出发方向的车集结得差不多了，再把各股道上的车组连挂成一列，做技检、试风，拉到出发场。这条主线上，现场的人最忙，系统要管的信息流是六个节点：到达确报、解体计划、钩计划、作业通知单、执行回执、现车更新。
这里说的“钩”，是调车作业的最小动作单位——把几辆车从车列中摘出、溜到另一条股道，或者把两段车挂在一起，都算一钩。一个白班下来，一台调车机干几十钩到上百钩都很正常。系统要能回答的问题就两个：下一钩去哪、刚才那一钩做完没有。回答不了这两个问题，台账就是摆设。
还要说清楚一个边界：这套系统只做计划和台账的信息流，不碰进路控制。车往哪条道走、信号怎么开放，是联锁和车站行车组织的事，调车系统别越界。
2.2 按业务对象拆模块：车号、股道、钩计划、现车台账
调车系统里最核心的业务对象只有四个：车、股道、钩计划、现车台账。这四个对象是相互咬合的。一辆车从A股道溜到B股道，钩计划的状态要跟着变，台账的顺序要跟着变，如果程序里没把这三个变化放在一次事务里改，就会出现“车动了台账没动”的翻车现场。
常见做法是按对象拆模块，不要按界面拆：
- 基础数据维护：货车车号库（车型、载重、轴数、换长）、股道档案（有效长、容车数、用途、封锁/禁溜/禁会标记）、班组和人员。
- 计划管理：到达计划、出发计划、解体钩计划、编组钩计划。
- 作业执行：调车单生成、下发、确认、回执，以及钩状态流转。
- 现车管理：按股道展示当前停放的车辆顺序，支持溜放、连挂、牵出三类动作自动改账。
- 统计与交接班：钩数统计、作业时长、班次保留车数、交接班快照。
这套边界划下来，程序里的用户角色也就清楚了：调车区长负责编计划和派单，调车组负责收单和回执，值班员盯现车和股道占用。三个角色对应到程序里就是计划模块、作业模块、现车监视三个界面，别做成一个大杂烩窗体。
2.3 技术选型为什么还是C#：桌面端、设备接口与Access/SQL Server的现实
选C#不是情怀，是现场条件决定的。车站办公终端大量还是Windows 7和Windows 10 32位的老机器，WinForms程序绿色部署、双击即用，不需要装JRE、不需要配Web容器。数据文件用SQL Server Express或者Access的.accdb都可以直接拷贝备份，车站的电务和信息技术人员看得懂,也敢动手。
设备接口这一层是C#最明显的优势。轨道衡、车号自动识别（AEI）、防溜设备、平面无线调车灯显，厂商多数给的是串口协议或者C/C++的DLL。C#上位机用SerialPort和P/Invoke对接非常顺，跟这些设备打交道本身就是C#工程师干惯了的活。换成Java或者Python，光是封装一个厂商DLL的调用约定就要多花不少功夫。
数据量方面，一个中等编组站一天200钩，现车台账也就是几千到上万条记录，单机Access就能扛住。想要双机热备、断点续传，再换成免费的SQL Server Express，也不需要额外花钱买授权。选型结论通常是：单站单机用Access起步，等要接第二台终端或者做远程查询时再迁SQL Server，表结构不用动，C#代码里换个连接串就行。
注意：这类调车辅助系统只做计划与台账的信息流，不参与进路控制。进路安全由联锁系统负责，别把控制功能做进这套程序里。
2.4 先跑通骨架：三张基础表和一段建表SQL
动手写界面之前，我一般先把三张基础表建出来：车辆档案表、股道档案表、钩计划表。这三张表能撑起“计划录入—拆钩—下发—回执—自动改现车”的最小闭环，后面的模块都是在这个骨架上长出来的。
-- 车辆档案表：一车一条 CREATE TABLE tbl_Car ( CarNo VARCHAR(14) NOT NULL, -- 车号，含车型字母，全路唯一 CarType VARCHAR(10), -- 车型，如 C64、P70 LoadFlag CHAR(1) DEFAULT 'E', -- E=空车，F=重车 AxleCount INT DEFAULT 4, -- 轴数，计算防溜和容车用 NoShuntFlag CHAR(1) DEFAULT 'N', -- Y=禁溜车/关门车，溜放时不能用 TrackNo INT, -- 当前股道，冗余列，台账展示快 Position INT, -- 股道内顺序位，1为靠道口端 PRIMARY KEY (CarNo) ); -- 股道档案表 CREATE TABLE tbl_Track ( TrackNo INT PRIMARY KEY, TrackName VARCHAR(20), -- 显示名，如“编3道” UseType VARCHAR(4), -- 到发/编组/存车/走行 EffLen INT, -- 有效长（米） Capacity INT, -- 换算容车数 IsBlocked CHAR(1) DEFAULT 'N', -- Y=封锁 NoHumpFlag CHAR(1) DEFAULT 'N', -- Y=禁溜放 NoShuntFlag CHAR(1) DEFAULT 'N' -- Y=禁止调车作业 ); -- 钩计划表：一条记录一个钩 CREATE TABLE tbl_Hook ( HookID INT IDENTITY PRIMARY KEY, TrainID VARCHAR(30), -- 开行ID：日期+车次+到达时刻 TeamNo INT, -- 调车组/机车编号 HookSeq INT, -- 本作业内钩序 ActionType VARCHAR(4), -- HUMP=溜放 COUPLE=连挂 PULL=牵出 SrcTrack INT, -- 源股道 DstTrack INT, -- 目标股道 CarCount INT, -- 本钩辆数 Status VARCHAR(4) DEFAULT 'PEND', -- PEND/DOING/DONE/CANCEL CreateTime DATETIME, DoneTime DATETIME );几个字段的逻辑说清楚。tbl_Car里冗余了TrackNo和Position，看起来违反第三范式，但现车台账的界面要频繁“按股道按顺序”整列展示，冗余这两个字段能少两次联查。Position的语义是“从道口端数过来第几位”，溜放一钩后，后面整串车的Position都要前移，这笔账必须在ApplyShunt里一次性算完。tbl_Hook里特别加了NoShuntFlag对应的字段提醒，虽然它在车辆表里，但钩计划的校验逻辑每钩都要查它，别图省事只查股道容车数。
骨架跑起来以后，主界面就分三块：左边按股道展示现车台账，右边列待派的钩计划，下面显示选中钩的明细和状态。能做到这一步，一个可演示的最小系统就成立了，后面加的模块不会推翻这个骨架。
3. 核心算法：钩计划生成与现车变更，把这两块写对就成了一半
3.1 钩计划生成：股道存车约束下的“车厢移动清单”
钩计划生成表面上是排顺序，本质上是把一列“按现场顺序排列的车辆序列”切成若干连续段，每段指定一个去向股道。因为溜放只能从车列端部逐钩连续进行，钩序天然是线性的，不能像排课表那样随意调换顺序。这也是为什么很多从订单系统转过来的开发会把钩计划做成“先定目标股道再排序”，结果一到现场就被打回——物理动作决定了切分顺序。
常见做法是半自动生成：算法先把连续同去向的车组合并成一个候选钩，再检查目标股道容车数、封锁状态和禁溜约束，不满足的钩不自动拆，直接标成“需人工确认”。这样既减少溜放次数，又把安全判断留给人。
public List<HookItem> BuildHooks( List<CarInTrain> cars, Dictionary<string, string> carToDestTrack) { var hooks = new List<HookItem>(); int start = 0; while (start < cars.Count) { string dest = carToDestTrack[cars[start].CarNo]; int end = start; // 连续同去向的车合成一钩，减少溜放次数 while (end + 1 < cars.Count && carToDestTrack[cars[end + 1].CarNo] == dest) { end++; } var hook = new HookItem { Seq = hooks.Count + 1, DestTrack = dest, StartIdx = start, EndIdx = end, NeedManual = !ValidateTrack(dest, end - start + 1, cars.GetRange(start, end - start + 1)) }; hooks.Add(hook); start = end + 1; } return hooks; } private bool ValidateTrack(string destTrack, int carCount, List<CarInTrain> group) { // 完整版要查库里三样东西： // 1) 目标股道未封锁 // 2) 目标股道剩余容车数 >= carCount // 3) 组内没有禁溜车/关门车 // 这里只写最小检查，其余留给人工确认 return !group.Any(c => c.NoShuntFlag == "Y"); }这段代码的关键在两个地方。一是内层while把连续同去向的车合并成一钩，这是提高解体效率的核心策略，钩数越少，调车机往返次数越少；二是NeedManual标记而不是自动重排，生产环境下“排错一钩”比“少排一钩”危险得多，算法不确定时把决定权交还给调车区长，界面标红让他确认。参数方面，cars必须按现场车辆顺序传入，不能按车号排序后又传进来；carToDestTrack的映射来自到达确报里的到站/品类字段，通常由调度员事先维护好“去向—股道”对照表。
3.2 现车变更：溜放、连挂、牵出对应三种数据结构操作
现车台账用什么数据结构存，直接决定改账逻辑好不好写。我用的是最朴素的方式：每条股道一个List<CarInfo>，列表顺序就是股道内从道口到对岸的车辆顺序。三个调车动作对应三种列表操作：溜放是源股道尾部取一组、挂到目标股道尾部；连挂是目标股道整列挂到源股道尾部；牵出是源股道靠道口一端取车、放到目标股道靠道口一端。
public void ApplyShunt(ShuntAction action, TrackStore trackStore) { switch (action.ActionType) { case "HUMP": // 溜放：源股道尾部取一组 -> 目标股道尾部 var group = trackStore.PopTail(action.SrcTrack, action.CarCount); trackStore.AppendTail(action.DstTrack, group); break; case "COUPLE": // 连挂：目标股道整列挂到源股道车列尾部 var whole = trackStore.TakeAll(action.DstTrack); trackStore.AppendTail(action.SrcTrack, whole); break; case "PULL": // 牵出：源股道靠道口一端取车 -> 目标股道 var head = trackStore.PopHead(action.SrcTrack, action.CarCount); trackStore.PrependHead(action.DstTrack, head); break; } trackStore.Version++; // 每次变更全局版本+1，供增量同步使用 _audit.Append(new ShuntAuditRecord { Time = DateTime.Now, Operator = action.Operator, ActionType = action.ActionType, SrcTrack = action.SrcTrack, DstTrack = action.DstTrack, CarCount = action.CarCount }); }这三个动作的语义要跟现场工人的说法对齐。溜放从尾部取车，因为溜放作业是把车列推到牵出线后，车组从车列尾部逐段溜出；牵出从头部取车，因为牵出作业是机车带着靠咽喉区一端的一部分车转线；连挂则是把另一条股道整列拉过来接上。代码里最容易踩坑的是方向搞反——如果现场把“道口端”定义成股道的另一端，PopHead和PopTail全反，台账会越改越乱。我一般会在股道档案里加一个字段注明“道口端方向”，并在界面用箭头画出来。
改账还有一个原则：现车台账只能由回执驱动，不能让人直接在台账界面上拖车改顺序。回执触发ApplyShunt，审计表记一条，版本号加一，整个过程可回溯；如果允许手拖，出事后谁也说不清是哪一下改坏的。
3.3 操作流与界面：调车区长派单、现场收单、回执改账
界面按三条栏来做比较顺手：左侧是现车台账，每个股道一行，车号按顺序横向排列；右上是待派的钩计划列表；右下是当前选中钩的车辆明细和状态。调车区长选中一个计划，点击“生成钩计划”，系统按3.1的算法出钩序，他逐个确认后选择调车组和机车，点击派单。派单动作就是把钩计划落库并把状态置为PEND。
现场终端的作业通知单可以做成网页，也可以做C#精简客户端，这个看终端硬件条件。每条钩在调车组侧有三个操作：接单、开始、完成。接单时状态从PEND变DOING，完成时从DOING变DONE，同时把回执传回服务器触发ApplyShunt。状态流转的规则要写死，不能让操作员跳状态。
| 状态 | 含义 | 触发动作 |
|---|---|---|
| PEND | 计划已生成，等待派单 | 调车区长确认并派单 |
| DOING | 已开始执行本钩 | 调车组点“开始” |
| DONE | 本钩完成，台账已变更 | 调车组点“完成”并回传回执 |
| CANCEL | 计划取消/作废 | 调车区长取消并写明原因 |
现场网络差是常态，终端离线时也要能收单和回执。常见做法是终端本地存一份作业缓存，回执先落本地，等网络恢复后按HookID批量上传，服务器按ID去重。这个闭环能不能跑通，决定了系统是“数字台账”还是“另一本手账”。
4. 作业单下发与回执：消息格式、增量同步和设备接入
4.1 消息格式：为什么落盘用XML、对外接口用JSON
调车作业单是要跨终端传递的作业指令，而且现场经常有离线作业、补传回执的场景，消息必须“可缓存、可重发”，不能依赖在线调用。常见做法是内部落盘用XML文件，对外接口用JSON。XML在这条链路里的优势是Schema可校验、编码可控，而且现场几年前的老终端即使没有JSON库也能读；JSON则留给跟外部系统对接，更轻量、更好解析。
C#里做XML序列化很方便，一个DTO加XmlRoot特性就行。下面是把一张作业单序列化成XML的核心代码：
[XmlRoot("WorkOrder")] public class WorkOrderMessage { [XmlAttribute("HookID")] public string HookID { get; set; } [XmlAttribute("Version")] public long MsgVersion { get; set; } [XmlElement("ActionType")] public string ActionType { get; set; } [XmlElement("SrcTrack")] public int SrcTrack { get; set; } [XmlElement("DstTrack")] public int DstTrack { get; set; } [XmlElement("CarCount")] public int CarCount { get; set; } [XmlElement("CarNumbers")] public string CarNumbers { get; set; } [XmlElement("Sign")] public string Sign { get; set; } } public string SerializeOrder(WorkOrderMessage msg) { var xs = new XmlSerializer(typeof(WorkOrderMessage)); using var sw = new StringWriter(); xs.Serialize(sw, msg); return sw.ToString(); }几个参数的讲究：HookID必须全局唯一，用“日期+调车组+HookSeq”生成，它是幂等回执的凭据；CarNumbers是车号拼接串，终端收到后可以先本地比对车辆数再开工；Sign是用HookID加Version加车号串做的哈希签名，防现场有人手工塞一个假文件进来触发台账变更。文件命名建议用order_{HookID}_{Version}.xml，终端按文件名就能判断版本，不用打开文件体。
到发确报如果是从既有系统带过来的Excel，读的时候用NPOI或者ClosedXML，不要用Office COM，否则服务器上没装Office就直接罢工。对外接口如果用JSON，C#端直接定义同名DTO，System.Text.Json序列化就行，字段务必和XML版保持一致，免得两套字段名来回映射出错。
4.2 增量同步与幂等回执：C#代码里的三个关键点
终端和服务器之间的同步，最怕的不是网络断，是“断完后续不上”。我采用的方案是全局版本号加增量拉取：服务器每发生一次台账变更，全局Version加一，客户端每次拉取时上报自己本地已应用到的版本号，服务器只返回比它新的数据。
public List<WorkOrderMessage> PullIncrement( string deviceId, long lastVersion) { return _db.WorkOrders .Where(o => o.MsgVersion > lastVersion) .OrderBy(o => o.MsgVersion) .Take(200) // 一次最多拉200张，防批量刷爆 .Select(o => ToMessage(o)) .ToList(); } public bool SaveAck(string hookId, string ackResult) { if (_db.Acks.Any(a => a.HookId == hookId)) return false; // 幂等：重复回执直接忽略 _db.Acks.Add(new AckRecord { HookId = hookId, Result = ackResult }); _db.SaveChanges(); ApplyHookDone(hookId); // 回执落库后才触发台账变更 return true; }这里三个关键点。第一，增量查询条件用MsgVersion大于而不是用时间大于，因为现场终端的时钟经常不准，跨库比较时间没有任何可信度；版本号是long型单调递增，不存在回拨问题。第二，Take(200)是给断点续传兜底的，终端离线一整天后重新上线，增量可能有上千条，一口气全传过去会把老终端内存打爆；客户端拿到一批后更新本地版本，再带着新版本拉下一批。第三，SaveAck的幂等不能只靠先查后插，两个终端同时回执同一钩时存在并发窗口，正确做法是给Acks表的HookId建唯一索引，插入冲突就直接返回“已处理”。
4.3 设备接入：串口参数表与状态上报的留底原则
调车系统要接的设备主要是车号自动识别AEI、轨道衡、防溜设备，以及轨道占用状态的采集。这些设备大部分走串口，参数是现场设备固死的，不是程序想改就能改。常用的参数组合我整理成了一张表：
| 参数 | 常见取值 | 说明 |
|---|---|---|
| 波特率 | 9600 / 4800 | 多数老设备固定9600，新设备支持自适应 |
| 数据位 | 8 | 少数老协议用7 |
| 停止位 | 1 | 个别设备用2，极罕见 |
| 校验 | 无 / 偶校验 | 先看设备说明书，猜了容易丢帧 |
| 读超时 | 500ms ~ 2000ms | 太短会把慢设备正常响应误判成断线 |
| 重连间隔 | 10s ~ 30s | 串口线接触不良时，重连太快会刷日志刷爆 |
AEI的对接逻辑通常是：轨边设备触发后，串口吐出一串车号和位置信息，C#上位机接收后形成“车辆到达序列”，再和到达确报里的“应有车号”做比对，不一致就报“车号核对不符”，让值班员人工介入。这个比对是替代人工抄号的关键一步，别把它做成“只记录不提示”。
轨道占用状态的上报要留底。程序收到的原始字节先写进原始报文表，再做解析，解析结果写状态事件表，最后才影响现车台账。任何一步都不能直接改台账，否则设备抖动一次，台账就跟着错一次。解析状态字时按位拆，用枚举把每一位的语义定义好，别写一堆魔法数字在代码里到处飘。
5. 避坑：调车系统生产环境最常翻车的五个地方，每条都是血泪经验
5.1 同车次复用导致现车错乱：问题出在开行ID没做够强的主键
现象：同一天两趟相同车次号的列车先后进站，系统按车次查计划，把后一趟的编组顺序盖到了前一趟车上，现车台账整列串号。
原因：车次号不是唯一键。同一个车次在同一天会因上下行方向、区段运行图不同而出现两次，如果不把“到达时刻”和“股道”纳入标识，程序永远分不清这两趟车。
解决：给每趟车生成独立开行ID，规则用“日期+车次+到达时刻（精确到分钟）”，所有钩计划、回执、台账修改都挂这个ID，查询只认它。车次号演变成展示字段，不再参与任何逻辑判断。
5.2 钩计划排好到现场“说不对”：缺了股道约束和禁溜校验
现象：算法按去向分组合并生成了一份钩序，现场反馈某钩溜不进去——目标股道已经有存车，有效长不够，或者钩组里混了一辆禁溜车。
原因：生成钩序时只看了“车辆去向相同”，把目标股道的剩余容车数、封锁状态、禁溜/关门车约束全漏了。这是把钩计划当成排课表在排的通病。
解决：把ValidateTrack做成强制约束链：先查目标股道未封锁，再查剩余容车数够不够，最后逐辆查组内有没有NoShuntFlag为Y的禁溜车。任一不满足就标NeedManual，界面标红，必须人工确认后才能派单。宁可让算法少排一钩，也别让它排错一钩。
5.3 现场终端显示旧台账：增量同步的版本号被客户端拖死
现象：终端重启后显示的股道车列和调度室不一致，刷新也无济于事，过很久才恢复正常。
原因：客户端拿着自己缓存的旧版本号去拉增量，服务器如果拿这个旧版本做基准，中间跨越的版本会被当成“已同步”丢掉；或者客户端版本号比服务器还高，后续增量永远拉不到。
解决：版本号以服务器为唯一权威。客户端只上报“我看到的版本”，服务器返回当前全局版本和增量列表，客户端应用完直接把自己的本地版本覆盖成服务器的值。版本号用long型单调递增，别用DateTime，时间回拨一次就全乱。
5.4 轨道占用闪烁误改了台账：状态机没做消抖
现象：股道占用状态突然从空闲变成占用，一秒后又跳回空闲，系统在这段时间里把“占用”当成了真实溜放动作，台账多出了几辆车。
原因：轨道电路或计轴设备受电气干扰，串口丢帧后读到了异常状态字，程序单次采样就直接写库。这就是典型的设备信号抖动。
解决：轨道占用状态用状态机管理，空闲到占用必须连续N次采样确认才翻转，N取3、采样间隔500ms起步；翻转后把事件带时间戳写入EventLog，台账变更与事件绑定，事后可以逐帧回查。状态机这层消抖逻辑是设备接入层最值得花时间写对的地方。
5.5 交接班两本账打架：缺审计表的补课
现象：白班夜班交接时对不上现车，A说溜了三钩、B说只收到两钩回执，谁改过台账根本查不到。
原因：所有变更都是直接Update数据库记录，没有审计表，操作人、操作时间、变更前后内容全没留。
解决：第3章的ApplyShunt里强制写ShuntAudit表，字段至少包括作业ID、操作人、动作类型、源/目标股道、辆数、时间戳。交接班时对每个股道打一次快照存表，次日交班直接比对两次快照差异，哪里对不上立刻定位到人、到钩、到时间。记录比解释重要，这是这套系统最值得花的一笔投资。
6. 验证与进阶：让历史作业“重跑一遍”，证明系统这次改对了
6.1 回放模式：算法层对不对，让日志自己说话
系统上线后最怕的不是没功能，是“这次发版到底改坏没有”。我给系统加了一个回放模式：把历史某一天的全部回执按原时间序重新执行一遍，每一步调用ApplyShunt，重算出当天的现车台账，再和当天派单时保存的台账快照比对。两条账对得上，算法层就是一致的；对不上，程序会把第一个不一致的钩子打印出来，直接定位是哪个动作算错。
这个回放跑在只读副本上，不影响生产数据，想跑几遍跑几遍。每次改完钩计划生成规则或现车变更逻辑，我都先把过去一周的数据重放一遍再上现场，比上线后拿真实作业去试错稳得多。
6.2 模拟时钟压测：把一昼夜的作业量塞进内存跑完
真实现场没法加速时间，但压测可以。做法是把系统里的时间源抽成一个可注入的Clock接口，生产环境用真实时间，测试环境用模拟时钟。模拟时钟连续推进24小时，灌入上百张计划、上千钩回执，跑完后检查股道列表的内存增长、版本号递增是否连续、增量同步是否丢数据。边界问题像“凌晨换班时来计划”“同一股道连续溜放十几钩”都会在压测里现形。
6.3 交付前三个小功课：自动备份、程序集合并、反编译防护
交付前的三个小功课我一般不会省。一是自动备份，每天下夜班前把数据库复制到另一台机器，保留14天，出问题有后悔药。二是程序集合并，用Costura.Fody把所有依赖DLL合并进主程序，免得现场漏带文件或者DLL版本冲突，拷过去一个exe就能跑。三是反编译防护，C#程序集用混淆工具处理一遍，至少挡住“反编译就抄内部逻辑”的初级操作者；连接串和关键密钥不要明文躺在配置文件里。
回放这个习惯回头看看救了我好几次。早年我最自信的就是“算法写得对”，后来发现系统上线后真正把台账搞乱的，很少是纯算法问题，大多是链路一致性——回执丢了、版本号过期、设备状态闪断。所以后来交付前我必先跑一遍历史回放，再盯一整天现场交接班。这套系统的价值就在这：它能把你从人肉接力里救出来，但不能替你兜底所有边界，边界要靠一遍遍重放和审计记录去磨平。希望帮到你。
本文还有配套的精品资源，点击获取
