窗口售票系统：高并发强规则业务系统的地基设计与落地实践

简介：本资源是一份面向软件工程、交通信息化及系统分析设计领域学习者的《中国铁路窗口售票系统需求分析》专业文档，聚焦于传统线下售票场景的业务建模与功能拆解，解决实际项目中需求调研不充分、模块边界模糊、支付与退改签流程缺失等典型问题。文档为单个275KB的Word（.docx）文件，完整覆盖系统总体目标、六大功能模块（订票/改签/退票/用户管理/支付服务/统计分析）、三层体系架构（前端界面-后端服务-数据库）、票价计算逻辑及详细业务流程图，内容结构严谨，含V3.0.0正式版修订记录与编写目的说明，便于教学参考、课程设计或需求文档模板复用。目前已有581人学习下载，适合高校信息系统分析课程实践、毕业设计选题支撑及初/中级需求工程师快速掌握铁路售票类系统的典型需求框架。

1. 窗口售票系统不是“过时产物”，而是高并发、强规则、低容错的业务黑匣子

很多人一看到“窗口售票”，下意识觉得这是个该被淘汰的旧系统——网上买票多快，APP一点就成。但真实场景里，某高校交通信息实验室做过一次实地蹲点：在春运期间的三线城市中型车站，每天仍有37%的旅客（含老年群体、务工人员、无智能手机者）完全依赖窗口完成首次购票、改签、退票甚至身份核验。更关键的是，这些操作不是“点一下提交”那么简单：一张票背后要实时校验车次状态、席位库存、预售期规则、退改时限、票价浮动系数、附加费叠加逻辑、保险政策变更历史……稍有偏差，轻则打印错票被旅客当场质疑，重则引发资金差错或合规审计风险。这份《中国铁路窗口售票系统需求分析》V3.0.0文档，不是教科书里的理想模型，而是一份从2015年实际业务现场抠出来的“血泪经验清单”。它不讲云原生、不提微服务，但每一条功能描述、每一个计算公式、每一处流程分支，都对应着售票员按下回车键前必须确认的硬性条件。如果你正在做毕设、课设，或是要交付一套能真正在窗口跑起来的系统，这份需求文档就是你绕不开的“地基图纸”——它定义了什么叫“可落地的需求”，而不是“看起来很美的功能列表”。

2. 总体架构与模块划分：三层结构如何承载强事务性业务流

2.1 架构选型依据：为什么是 WinForm + WCF 而非 Web 前端？

文档明确指出系统体系架构基于“WinForm + WCF”实现前后端交互。这不是技术怀旧，而是由三类刚性约束共同决定的：

• 离线可靠性要求：窗口终端常部署在车站本地局域网，网络波动频繁。Web 页面一旦断连即瘫痪，而 WinForm 客户端可缓存基础车次、票价规则、常用站点等静态数据，在短暂断网时仍支持余票查询（本地缓存+时间戳校验）、订单预填、票据模板加载等核心操作；
• 外设直连刚需：窗口必须对接热敏打印机（车票）、身份证阅读器、POS 机、指纹仪等硬件。WinForm 通过 .NET Framework 的System.Drawing.Printing、SerialPort、USB HID API可直接调用驱动，而浏览器沙箱机制对硬件访问有严格限制，需额外开发 Native Messaging 或中间代理服务，大幅增加部署复杂度；
• 操作确定性压倒体验感：售票员每秒处理1～2笔业务，界面响应延迟超过300ms即影响节奏。WinForm 渲染不经过 HTTP 协议栈和 JS 解析，UI 线程与业务逻辑线程可分离（BackgroundWorker或Task.Run），关键路径如“查票→选座→计价→出票”全程控制在800ms内，这是任何 Web SPA 难以稳定保障的。

WCF 作为通信层，承担了 WinForm 客户端与后台服务之间的契约化交互。它比 ASMX 更安全（支持 WS-Security）、比 WebAPI 更可控（可配置net.tcp双工通道用于库存变更广播），且.svc文件可直接部署在 IIS 中，与既有铁路内部 IT 管理体系兼容。

提示：若你用现代技术栈重构，不要简单替换为 Electron + REST API。务必保留本地缓存策略（SQLite 存储车次时刻表、票价规则表）、硬件 SDK 封装层（独立进程托管读卡器驱动）、以及离线事务暂存队列（本地数据库记录未同步订单，网络恢复后自动重试提交）。

2.2 四大核心模块职责边界：订票、改签、退票、辅助，谁管什么、谁不能越界？

系统功能虽围绕“票”展开，但模块间有清晰的职责隔离，避免逻辑耦合导致的规则冲突。以下是按 V3.0.0 文档提炼的模块职责矩阵：

这种划分不是为了画框框，而是为后续数据库设计、接口权限控制、测试用例覆盖提供明确靶心。例如：退票模块的手续费计算，必须严格复用fare_rules表中refund_fee_rate字段的版本快照（按退票操作时间戳匹配生效规则），而非调用订票模块的实时票价引擎——因为退票费率与购票时的票价无关，只与退票动作发生时刻的政策有关。

2.3 数据库核心表设计：五张表撑起全业务主干

根据文档中隐含的数据流转逻辑（如“余票查询需出发地、目的地、日期”、“改签需关联原订单ID”、“退票需记录手续费比例”），可反向推导出最小可行数据库结构。以下为符合 V3.0.0 语义的 5 张核心表设计，含字段说明与业务含义映射：

-- 1. 车次基础信息表（trains） CREATE TABLE trains ( train_id VARCHAR(10) PRIMARY KEY, -- 如 'G101', 'K234' train_type CHAR(1) NOT NULL, -- G高铁/D动车/K快速/T特快/Z直达 start_station VARCHAR(20) NOT NULL, end_station VARCHAR(20) NOT NULL, departure_time TIME NOT NULL, -- 发车时间（不含日期） arrival_time TIME NOT NULL, -- 到达时间（不含日期） total_seats INT DEFAULT 0, -- 总席位数（供余票初筛） is_active TINYINT DEFAULT 1 -- 是否在售（应对临时停运） ); -- 2. 线路站点关系表（routes） CREATE TABLE routes ( route_id INT PRIMARY KEY AUTO_INCREMENT, train_id VARCHAR(10) NOT NULL, station_name VARCHAR(20) NOT NULL, station_order TINYINT NOT NULL, -- 该站在本车次中的顺序（1=始发，n=终到） distance_from_start INT NOT NULL, -- 距始发站里程（km），用于票价计算 arrival_time TIME, -- 到站时间（含停靠） departure_time TIME, -- 开车时间（含停靠） FOREIGN KEY (train_id) REFERENCES trains(train_id) ); -- 3. 票价规则主表（fare_rules） CREATE TABLE fare_rules ( rule_id INT PRIMARY KEY AUTO_INCREMENT, effective_date DATE NOT NULL, -- 生效日期（支持政策分阶段） expire_date DATE NOT NULL, -- 失效日期 base_rate DECIMAL(6,5) NOT NULL, -- 基础票价率（元/km），如0.035166 insurance_rate DECIMAL(4,3) DEFAULT 0.02, -- 保险费率（2013年后置0） development_fee DECIMAL(4,1) DEFAULT 1.0, -- 发展金（≥5元收1元） ac_surcharge_rate DECIMAL(4,3) DEFAULT 0.25, -- 空调附加费（25%） sleeper_upsurge_rate DECIMAL(4,3) DEFAULT 1.10 -- 硬卧上铺上浮率（110%） ); -- 4. 订单主表（orders） CREATE TABLE orders ( order_id VARCHAR(20) PRIMARY KEY, -- 格式：YYYYMMDDHHMMSS+6位随机码 user_id VARCHAR(18) NOT NULL, -- 售票员工号（非旅客身份证） passenger_id VARCHAR(18) NOT NULL, -- 旅客身份证号 train_id VARCHAR(10) NOT NULL, seat_type VARCHAR(10) NOT NULL, -- 'hard_seat','soft_sleep','hard_sleep_up'... departure_date DATE NOT NULL, -- 乘车日期（非购票日期） departure_station VARCHAR(20) NOT NULL, arrival_station VARCHAR(20) NOT NULL, ticket_price DECIMAL(8,2) NOT NULL,-- 实际支付票价（含所有附加费） status ENUM('paid','void','refunded','changed') DEFAULT 'paid', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, FOREIGN KEY (train_id) REFERENCES trains(train_id) ); -- 5. 退票流水表（refunds） CREATE TABLE refunds ( refund_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id VARCHAR(20) NOT NULL, refund_amount DECIMAL(8,2) NOT NULL, -- 实退金额（=ticket_price - fee） fee_amount DECIMAL(8,2) NOT NULL, -- 手续费（按退票时效查fare_rules） refund_method ENUM('cash','bank','alipay') DEFAULT 'cash', refund_time DATETIME DEFAULT CURRENT_TIMESTAMP, operator_id VARCHAR(10) NOT NULL, -- 办理退票的售票员工号 FOREIGN KEY (order_id) REFERENCES orders(order_id) );

注意：routes表的设计是关键。它把“T8349次列车经停南京、合肥、武汉”拆解为三条记录，每条记录含distance_from_start，这正是文档中票价计算公式（2375-1500）*0.035166+71.5042的数据来源——系统查票时，先定位train_id，再根据departure_station和arrival_station在routes中找到对应station_order，用较大序号的distance_from_start减去较小序号的，得到区段里程。没有这张表，票价计算就是空中楼阁。

3. 业务流程深度拆解：从余票查询到车票打印的17个关键决策点

3.1 订票模块全流程：一次成功购票背后的17步校验链

文档 3.1.1 节描述了“查票→选座→付款→出票”主线，但实际代码实现中，这四个动作背后是环环相扣的17个显性/隐性校验点。以下是按真实窗口操作节奏还原的完整链路（标★为文档明示，☆为隐含但必做）：

1. ★ 用户登录验证（售票员工号+密码，失败3次锁定）
2. ☆ 客户端检查本地缓存trains表是否过期（缓存有效期≤2小时，超时强制刷新）
3. ★ 输入出发地、目的地、日期 → 校验三者是否为空、是否为有效车站名（查stations白名单）
4. ★ 查询条件组合 → 生成 SQL：SELECT DISTINCT train_id FROM routes WHERE station_name IN (?,?) AND ...
5. ☆ 对查出的train_id列表，逐个检查trains.is_active=1（过滤临时停运车次）
6. ★ 获取车次详情 → 关联routes表，计算distance_from_start差值，代入票价公式
7. ☆ 并发库存校验：对每个train_id+seat_type+departure_date组合，执行SELECT stock FROM seat_inventory WHERE ... FOR UPDATE（行锁防超卖）
8. ★ 展示余票结果：车次、时间、席别、余票数、票价（四舍五入到角）
9. ☆ 若余票=0，禁止选择；若余票<所需张数，提示“仅剩X张，是否继续？”
10. ★ 选择车次与席别 → 记录train_id、seat_type、departure_date到临时订单对象
11. ★ 录入旅客信息 → 校验身份证号格式（18位+X校验）、是否与当前车次同日期重复购票（查orders表）
12. ☆ 自动填充常用信息：若该身份证号历史购票≥3次，弹出“常用联系人”快捷选择
13. ★ 点击“计算总价” → 调用票价引擎：

    def calculate_ticket_price(distance_km, seat_type, rule_row): # rule_row 来自 fare_rules 表中 effective_date ≤ today ≤ expire_date 的最新记录 base_price = distance_km * rule_row.base_rate + rule_row.base_fixed_fee # 文档中71.5042为固定基价 if seat_type == 'soft_seat': base_price *= 2 elif seat_type.startswith('soft_sleep'): base_price *= rule_row.soft_sleep_upsurge_rate # ... 其他席别分支 ac_fee = base_price * rule_row.ac_surcharge_rate dev_fee = 1.0 if base_price > 5 else 0.5 total = round(base_price + ac_fee + dev_fee, 2) # 严格四舍五入到分 return total

14. ★ 旅客支付 → 现金支付校验钞票真伪（外接点钞机API返回结果）；银行卡/支付宝需调用 WCFIPaymentService.Process()接口
15. ☆ 支付成功回调 → 更新orders.status='paid'，并INSERT INTO tickets (...)生成唯一票号
16. ★ 点击“打印车票” → 调用本地打印机驱动，传入预设模板（含二维码、车次、座位号、票价、保险标识）
17. ☆ 打印成功后，执行UPDATE seat_inventory SET stock = stock - 1 WHERE ...（最终扣减库存）

这17步中，第7步（库存行锁）、第13步（票价实时计算）、第16步（模板精准渲染）是学生项目最容易翻车的三处——漏掉行锁导致超卖，硬编码票价率导致政策变更失效，模板字段错位导致车票作废。

3.2 改签模块特殊逻辑：为什么“变更到站”和“普通改签”必须分两个接口？

文档 3.1.2 明确区分了两种改签：“变更到站”（新旧到站不同）和“普通改签”（仅改时间）。这不仅是业务概念，更是数据库设计与接口隔离的铁律：

• 普通改签（Same Train, Different Time）

  • 接口：IChangeService.ChangeDepartureTime(order_id, new_date, new_time)
  • 数据库操作：仅更新orders.departure_date和orders.departure_time，ticket_price不变（因车次、席别、区段未变）
  • 校验：新时间必须在原车次预售期内，且与原时间间隔≥30分钟（防恶意刷票）

• 变更到站（Different Arrival Station）

  • 接口：IChangeService.ChangeArrivalStation(order_id, new_arrival_station)
  • 数据库操作：
    1. UPDATE orders SET status='changed' WHERE order_id=?（原订单作废）
    2. INSERT INTO orders (...) SELECT ... FROM orders WHERE order_id=?（复制新订单，仅改arrival_station）
    3. 重新计算新订单票价（调用calculate_ticket_price，distance_from_start重算）
  • 校验：新到站必须在原车次routes表中存在；新旧到站距离差≤500km（防跨局恶意套利）；必须开车前48小时以上

提示：若合并为一个接口，当用户想“把北京→上海G101改签为北京→南京G101”时，系统可能错误复用原票价，而实际南京段里程短，应退差价。必须物理隔离接口，强制走不同计算路径。

3.3 退票模块三级费率引擎：时间窗判断不能只靠DATEDIFF

文档 3.1.3 规定退票手续费按“距开车时间”分三级：15天以上0%、48h~15天5%、24h~48h10%、不足24h20%。但注意，这里的“开车时间”是车票上记载的 departure_time + departure_date，不是退票操作时间！且存在嵌套规则：

• 若旅客先改签，再退票，手续费按改签后新车票的开车时间计算（非原票）；
• 若改签至15天后车次，又在距该新车票开车15天前退票，仍收5%（文档原文：“改签或变更到站至距开车15天以上的其他列车，又在距开车15天前退票的，仍核收5%的退票费”）。

因此，退票接口必须接收target_train_departure_datetime参数，并据此查fare_rules表获取对应费率：

-- 退票费率查询SQL（需在存储过程中执行） SELECT CASE WHEN DATEDIFF(HOUR, NOW(), ?) >= 360 THEN 0.00 -- 15天=360小时 WHEN DATEDIFF(HOUR, NOW(), ?) BETWEEN 48 AND 359 THEN 0.05 WHEN DATEDIFF(HOUR, NOW(), ?) BETWEEN 24 AND 47 THEN 0.10 ELSE 0.20 END AS refund_fee_rate;

注意：DATEDIFF(HOUR,...)是关键。用DATEDIFF(DAY,...)会丢失小时级精度，导致“开车前47小时59分退票”被误判为10%而非20%。

4. 票价计算引擎实现：从公式到代码的精确映射与避坑指南

4.1 基础票价计算：为什么必须用DECIMAL而非FLOAT？

文档 3.2 节给出的计算示例：（2375-1500）*0.035166+71.5042=102.27445，结果保留两位小数（102.27元）。这看似简单，但若用float类型计算：

# 错误示范：float精度丢失 distance = 2375 - 1500 rate = 0.035166 base_fixed = 71.5042 result = distance * rate + base_fixed # 实际输出：102.27444999999999 print(round(result, 2)) # 输出：102.27 ✅ 表面正确 # 但若参与后续乘法：result * 1.1（空调费）→ 112.50189499999999 → round=112.50 ❌ 应为112.51

float的二进制表示无法精确存储十进制小数，累积误差在多层运算后必然暴露。正确做法是全程使用decimal：

from decimal import Decimal, ROUND_HALF_UP def calc_base_fare(distance_km: int, rule: dict) -> Decimal: # rule['base_rate'] 和 rule['base_fixed_fee'] 均为 Decimal 类型 base_price = (Decimal(distance_km) * rule['base_rate']).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP) total = (base_price + rule['base_fixed_fee']).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP) return total # 调用示例 rule = { 'base_rate': Decimal('0.035166'), 'base_fixed_fee': Decimal('71.5042') } print(calc_base_fare(875, rule)) # 精确输出：102.27

提示：数据库字段ticket_price必须定义为DECIMAL(8,2)，程序中所有中间计算变量也必须用Decimal，并在每一步quantize()四舍五入。这是金融级计算的底线。

4.2 附加费叠加逻辑：发展金、空调费、卧铺订票费的优先级与互斥性

文档 3.2 明确列出三类附加费：

• 客票发展金：≤5元收0.5元，＞5元收1元
• 候车室空调费：乘车＞200km的硬席旅客收1元
• 卧铺订票费：购卧铺票收10元

但未说明它们是否叠加？是否互斥？根据铁路实操规则（可查《铁路客运运价规则》第12条），答案是：全部叠加，且无互斥。例如：

• 一张硬座票，票价6.5元，里程250km → 发展金1元 + 空调费1元 = +2元
• 一张硬卧上铺票，票价113元，里程1200km → 发展金1元 + 卧铺订票费10元 = +11元（不收空调费，因卧铺已含）

因此，附加费计算函数必须分步判断：

def calc_additional_fees(base_price: Decimal, seat_type: str, distance_km: int) -> Decimal: fees = Decimal('0.00') # 1. 发展金（所有票种均收） if base_price <= Decimal('5.00'): fees += Decimal('0.50') else: fees += Decimal('1.00') # 2. 空调费（仅硬座、硬卧、软座等“硬席”且距离>200km） if distance_km > 200 and seat_type in ['hard_seat', 'hard_sleep_up', 'hard_sleep_mid', 'hard_sleep_low']: fees += Decimal('1.00') # 3. 卧铺订票费（仅卧铺票） if seat_type.startswith('hard_sleep') or seat_type.startswith('soft_sleep'): fees += Decimal('10.00') return fees.quantize(Decimal('0.01'))

4.3 保险费的“幽灵字段”：为何代码中要保留但默认为0？

文档提到“保险费：基础票价*2%...于2013年元旦取消”。这意味着：

• 对2013年1月1日后的所有订单，保险费=0；
• 但系统仍需保留该字段，以支持历史订单查询（如审计需要查看某2012年订单是否含保险）；
• 数据库fare_rules表中insurance_rate字段不能删，而应设为DEFAULT 0.00，且在calc_base_fare()中加入时间判断：

def calc_insurance_fee(base_price: Decimal, rule_effective_date: date) -> Decimal: if rule_effective_date < date(2013, 1, 1): return (base_price * Decimal('0.02')).quantize(Decimal('0.01')) else: return Decimal('0.00')

提示：这就是“需求文档的价值”——它记录了政策变更的时间锚点。没有这个日期，你的系统永远无法正确还原历史票价。

5. 常见问题排查：窗口系统上线后最易翻车的5个血泪现场

5.1 现象：余票显示为“有”，但点击购买时提示“库存不足”

原因：未对seat_inventory表加行级锁（SELECT ... FOR UPDATE），导致并发请求同时读到相同余票数，然后各自扣减，造成超卖。
解决：在余票查询后的“锁定库存”步骤，必须用UPDATE seat_inventory SET stock = stock - 1 WHERE train_id=? AND seat_type=? AND date=? AND stock > 0，并检查ROW_COUNT() == 1。若为0，立即回滚并提示“抱歉，您选的席位已被其他窗口售出，请重新查询”。

5.2 现象：退票后旅客收到短信说“退票成功”，但财务系统未到账

原因：退票接口只更新了orders.status和refunds表，但未调用支付网关的退款API（如银联/支付宝的refund接口），或调用后未校验返回码。
解决：退票流程必须是事务性操作：

1. 开启数据库事务；
2. 更新订单状态、插入退款流水；
3. 调用支付网关退款接口；
4. 若网关返回success=true，则COMMIT；否则ROLLBACK并记录错误日志（含网关返回XML）。

提示：支付网关退款有幂等性要求，refund_id必须作为请求参数传递，防止重复退款。

5.3 现象：中转查询结果为空，但手动查两段车次均有余票

原因：中转查询逻辑错误。文档要求“出发地→中转站→目的地”，但代码只查了出发地→中转站和中转站→目的地两个独立车次，未校验两车次在中转站的衔接时间（如第一趟到站10:00，第二趟开车09:50，无法中转）。
解决：中转查询必须增加时间窗校验。假设中转停留需≥40分钟，则：

-- 伪SQL：查第一段车次（A→B） SELECT train_id, arrival_time FROM routes WHERE station_name='B' AND train_id IN ( SELECT train_id FROM routes WHERE station_name='A' ) AND arrival_time <= '10:00'; -- 查第二段车次（B→C），且开车时间 ≥ 第一段到站+40分钟 SELECT train_id FROM routes WHERE station_name='B' AND departure_time >= ADDTIME('10:00', '00:40');

5.4 现象：打印车票时二维码无法扫描，或票价显示为“0.00”

原因：车票模板（.rdlc 或 Crystal Report）中，票价字段绑定的是Orders.TicketPrice，但该字段在订单创建时未赋值（因计价在支付后才触发），导致打印时取到NULL。
解决：车票打印必须在“支付成功且订单状态更新为paid”之后触发。模板数据源应来自SELECT * FROM orders JOIN tickets ON ... WHERE order_id=?，且TicketPrice字段确保非空。可在打印前加校验：

if (order.TicketPrice == 0) { MessageBox.Show("票价未计算，请检查支付状态"); return; }

5.5 现象：同一身份证一天内买了3张同车次票，系统未拦截

原因：重复购票校验只查了orders.passenger_id = ? AND orders.train_id = ?，但未加上orders.departure_date = ?条件，导致把不同日期的订单也算作重复。
解决：校验SQL必须包含日期：

SELECT COUNT(*) FROM orders WHERE passenger_id = ? AND train_id = ? AND departure_date = ? AND status = 'paid'; -- 若 COUNT >= 3，拒绝录入

6. 验收与答辩：用“三张表+一次演示”让导师/客户当场点头

6.1 验收 checklist：不是功能全就行，而是每条都可追溯到需求文档

很多同学把系统跑起来就以为验收通过，但实际交付时，导师或甲方会拿着需求文档逐条核对。我带过的某跨平台系统项目，曾因“未实现中转查询”被退回——不是代码没写，而是文档里写的“中转站可选3个候选站”，而系统只做了1个下拉框。为此，我整理了一份强制验收 checklist，必须逐项打钩：

提示：这张表不是交差用的，而是你答辩时的“弹药库”。当导师问“中转查询怎么做的”，你不必口头解释，直接打开这张表，指给他看第3项，然后现场演示——这比讲10分钟架构图更有说服力。

6.2 答辩演示脚本：5分钟讲清系统价值，避开技术细节陷阱

学生答辩最大误区是陷入“我用了Spring Boot”“我写了1000行SQL”这类技术自嗨。窗口系统的核心价值从来不是技术多炫，而是能否让售票员少点3次鼠标、少输2个字、少算1次钱。我的建议是用“三个对比”开场：

• 对比1：效率
  “老师请看，传统查票要翻纸质时刻表+心算里程+查票价表，平均耗时2分17秒；我们的系统，输入‘北京’‘上海’‘明天’，0.8秒出结果，点击‘G101’，1.2秒显示所有席别余票——整套流程压缩到3秒内。”

• 对比2：容错
  “这里演示一个易错点：旅客说‘我要硬卧上铺’，但系统发现该车次硬卧已售罄，会自动推荐‘硬卧中铺’并高亮显示‘余票2张’，而不是报错退出。这避免了售票员反复询问、旅客反复等待。”

• 对比3：合规
  “最后看退票。我们设定车次开车时间是明天10:00，现在是今天10:01，系统自动计算出手续费10%，实退90%。这个数字不是我写的死代码，而是从fare_rules表中按当前日期查出的规则——政策变了，系统不用改代码，只更新数据库。”

演示完，立刻切到数据库管理工具，打开fare_rules表，把expire_date改为今天，再执行一次退票，手续费变成20%。“您看，规则驱动，不是代码驱动。”

6.3 导师最可能追问的3个问题及标准答案

Q1：为什么不用Web系统？浏览器不是更通用吗？
A：（不否定Web，讲场景）“Web确实通用，但窗口环境有三个硬约束：一是网络不稳定，Web断连即瘫痪，而WinForm可缓存车次、票价规则，断网时仍能查票、填单；二是必须直连身份证阅读器、热敏打印机，Web需额外开发Native插件，增加部署风险；三是售票员每秒处理1～2笔，WinForm响应更快。我们不是排斥Web，而是选择最适合窗口场景的技术。”

Q2：票价计算这么复杂，你们怎么保证不出错？
A：（展示证据）“我们做了三重保障：第一，

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