企业官网建设流程全解析

简介：这份面向数据库课程设计与Java桌面开发入门者的宾馆管理系统课设包，采用SQL Server存储数据、Swing搭建操作界面，可作为酒店管理类课程设计的完整参考，也适合想练习桌面端数据库应用开发的学生对照学习。压缩包共40个文件、约2.02MB，内含SQL建库脚本、数据库主数据与日志文件、Java源代码、编译后的类文件、可执行程序及使用说明文档，并保留工程配置和界面布局依赖，基本覆盖建库建表、源码阅读、程序运行与文档整理等环节。已有379人学习下载，说明其在同类课设中具有一定参考价值；读者可据此了解宾馆管理系统的模块划分、数据库落库过程和Swing界面组织方式，也能拆解源码、复现运行环境，并在此基础上调整功能或撰写自己的课程设计说明。

1. 宾馆管理系统课设：从一张房态表倒推整套数据库与桌面端方案

客房部前台最怕的不是忙，是信息对不上。客人站在柜台前，电脑里显示 302 空房，房卡却刷不开门；夜审时发现三笔订单重复占用同一间房；交接班要靠一张手写纸记“今天谁退房、谁续住”。这类问题的根子不在界面好不好看，而在数据库有没有把“房间状态”这一个事实管住。数据库课设里选“宾馆管理系统”的人很多，但真正能讲清楚房态流转、外键约束、并发改房的人不多。这套基于 SQL Server + Swing 的桌面端方案，适合数据库课程设计、Java 桌面应用课设，也适合想练一遍“建表 — 约束 — 事务 — 界面联动”完整链路的同学。它要解决的核心问题是：让房态只有一处数据源，所有入住、退房、换房动作都变成一次受约束的数据库写入。

Swing 在今天不算时髦，但放在课设场景里它是合适的选择：纯 JDK 自带，无需搭前端工程，编译即运行，导师当面验收时双击就能演示。SQL Server 的优势则在约束与事务的表达力——CHECK、外键、唯一索引、存储过程能直接把业务规则写进数据库层，而不是全堆在 Java 代码里。这也是数据库课设该拿分的地方：你的分数不完全来自界面，而来自“数据库设计是否体现了业务约束”。下面的内容按需求、库表设计、事务实现、界面联动、避坑、答辩验收的顺序展开，每一章都能直接落到你那份文档和代码里。

2. 需求与库表设计：把房态规则先写进数据库

2.1 从业务流程抽出四类核心实体

动手建表之前，先把业务走一遍。宾馆管理的主干流程其实很短：客人到店 → 查空房 → 登记入住 → 生成账单 → 退房结算 → 房间转待清扫 → 清扫完成转空闲。围绕这条线，实体收敛为四类：客房（Room）、客房类型（RoomType）、客人（Guest）、入住单（CheckIn），再加两张辅助表：订单/账单（Bill）和用户（SysUser，供前台登录）。有些同学一上来就画十几张表，把餐饮、会议室、会员积分全塞进来，最后每张表只有两三个字段，答辩时被问“这张表和外键关系是什么”就卡住。课设阶段表不在多，在于每张表都有人用、每个外键都有业务含义。

判断一张表该不该留的标准很朴素：它是否参与房态流转或金额计算。餐饮消费如果不做，就别建；如果做了，就必须挂到入住单上，否则账单算不出来。我一般会先在纸上写清楚“一次入住会产生哪几条记录”，再反推表结构，比直接打开 SSMS 建表效率高得多。

房态是整套系统的核心状态机，取值必须收敛。常见的错误是用中文“空闲/已住/维修”直接存字符串，后续查询和判断到处都是字符串比较，还容易因为多打一个空格导致状态对不上。正确做法是用数值或定长编码加 CHECK 约束：

-- 房间表：房态用数值编码，并用 CHECK 约束把非法状态挡在数据库外 CREATE TABLE Room ( RoomNo VARCHAR(10) PRIMARY KEY, -- 房号，如 '302' TypeId INT NOT NULL, -- 所属房型 FloorNo INT NOT NULL, -- 楼层，便于按层查询 Status TINYINT NOT NULL DEFAULT 0, -- 0空闲 1已入住 2待清扫 3维修 Remark NVARCHAR(100) NULL, CONSTRAINT FK_Room_Type FOREIGN KEY (TypeId) REFERENCES RoomType(TypeId), CONSTRAINT CK_Room_Status CHECK (Status IN (0, 1, 2, 3)) );

这段的关键不在语法，在CK_Room_Status。有了它，任何绕过业务代码的直接 UPDATE 都无法写入状态 7 这种脏数据。TypeId上的外键则保证房型不会指向一张已被删掉的类型记录。FloorNo单独存一列，是为了“按楼层看房态”这种前台常见操作不用去解析房号字符串——用SUBSTRING拆房号虽然能跑，但索引失效，房量一多就慢。

2.2 入住单表与账单表：金额和状态都要可追溯

入住单是业务的心脏，它同时承担“谁住在哪间房、什么时候来、什么时候走、算多少钱”四件事。设计时最容易翻车的是把房价直接写死在入住单里而不留快照，等房型调价后，历史账单全被改写。正确做法是入住时把当时的房价抄一份进入住单：

CREATE TABLE CheckIn ( CheckInId INT IDENTITY(1,1) PRIMARY KEY, RoomNo VARCHAR(10) NOT NULL, GuestId INT NOT NULL, CheckInTime DATETIME NOT NULL DEFAULT GETDATE(), PlanOutTime DATETIME NOT NULL, -- 预计离店 RealOutTime DATETIME NULL, -- 实际离店，未退房为 NULL PriceSnapshot DECIMAL(10,2) NOT NULL, -- 入住时房价快照 Deposit DECIMAL(10,2) NOT NULL DEFAULT 0, -- 押金 Status TINYINT NOT NULL DEFAULT 1, -- 1在住 2已退 3已取消 CONSTRAINT FK_CheckIn_Room FOREIGN KEY (RoomNo) REFERENCES Room(RoomNo), CONSTRAINT FK_CheckIn_Guest FOREIGN KEY (GuestId) REFERENCES Guest(GuestId), CONSTRAINT CK_CheckIn_Status CHECK (Status IN (1, 2, 3)), CONSTRAINT CK_CheckIn_Time CHECK (RealOutTime IS NULL OR RealOutTime >= CheckInTime) );

PriceSnapshot是整个设计里最容易被忽略、又最能体现思考深度的一列。答辩时如果导师问“房型涨价了，上个月的账单会不会变”，你能指着这一列回答，分数就稳了。CK_CheckIn_Time把“退房时间不能早于入住时间”写进约束，避免界面传参出错时产生负时长订单。

账单表则只做汇总，不重复存明细价格。它记录应收、实收、结算方式与结算时间，通过CheckInId关联回入住单。注意账单与入住单是一对一还是多对一，取决于你是否支持中途结部分账——课设通常做一对一足够，用UNIQUE约束住CheckInId即可，同时天然防止同一入住单开出两张账单。

还有一张表容易被做漏：操作日志（OperateLog）。前台换房、改价、强制退房这些动作，出问题时必须有迹可循。日志表不需要复杂，记下操作人、时间、动作类型、涉及房号、变更前后状态就够。它不参与业务计算，但在答辩演示“数据是怎么变的”时非常好用，也是很多同学方案里缺的那一块。

3. 房态流转的实现：事务、存储过程与并发控制

3.1 一次入住必须是一个原子事务

入住操作要同时做三件事：往 CheckIn 插一条记录、把 Room 的状态从 0 改成 1、必要时更新客人信息。这三步如果分开执行，中间任意一步失败就会留下“房间被占但没有入住单”或者“有入住单但房间还是空闲”的脏数据。课设演示时如果导师在你点完按钮的瞬间拔网线（虽然夸张，但断点调试、异常抛出都可能造成同样结果），数据就不一致了。

正确写法是把它们包在一个事务里，并且先做房态校验再更新：

// 入住核心逻辑：校验房态 + 插入入住单 + 更新房态，三步同一事务 public boolean checkIn(String roomNo, int guestId, int days, double deposit) { Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交，开启事务 // 1. 锁定并校验房态，防止两人同时抢同一间房 String checkSql = "SELECT Status, Price FROM Room r " + "JOIN RoomType t ON r.TypeId = t.TypeId " + "WHERE RoomNo = ? FOR UPDATE"; double price; try (PreparedStatement ps = conn.prepareStatement(checkSql)) { ps.setString(1, roomNo); ResultSet rs = ps.executeQuery(); if (!rs.next()) throw new BizException("房号不存在"); if (rs.getInt("Status") != 0) throw new BizException("该房间当前不可入住"); price = rs.getDouble("Price"); } // 2. 插入入住单，价格取当前房型价作为快照 String insSql = "INSERT INTO CheckIn(RoomNo, GuestId, PlanOutTime, PriceSnapshot, Deposit, Status) " + "VALUES(?, ?, DATEADD(DAY, ?, GETDATE()), ?, ?, 1)"; try (PreparedStatement ps = conn.prepareStatement(insSql)) { ps.setString(1, roomNo); ps.setInt(2, guestId); ps.setInt(3, days); ps.setDouble(4, price); ps.setDouble(5, deposit); ps.executeUpdate(); } // 3. 更新房态为已入住，条件里再带一次 Status=0 做双保险 try (PreparedStatement ps = conn.prepareStatement( "UPDATE Room SET Status = 1 WHERE RoomNo = ? AND Status = 0")) { ps.setString(1, roomNo); if (ps.executeUpdate() != 1) throw new BizException("房态已变更，请刷新"); } conn.commit(); return true; } catch (Exception e) { if (conn != null) try { conn.rollback(); } catch (SQLException ignore) {} throw new BizException("入住失败：" + e.getMessage()); } finally { if (conn != null) try { conn.setAutoCommit(true); conn.close(); } catch (SQLException ignore) {} } }

说明几点。setAutoCommit(false)是事务的开关，忘记关就等于没写事务。FOR UPDATE是行级锁，在 SQL Server 里对应的写法是WITH (UPDLOCK, ROWLOCK)，如果按 SQL Server 方言写，应改为在 FROM 子句后加锁提示：

SELECT Status, Price FROM Room WITH (UPDLOCK, ROWLOCK) JOIN RoomType t ON Room.TypeId = t.TypeId WHERE RoomNo = ?

UPDATE ... WHERE Status = 0里那个附加条件是双保险：即使前面的查询被绕过，更新时房态已变也会返回 0 行，触发回滚。这种“校验 + 条件更新”的写法是我在课设里最推荐给学生的，因为它不需要你理解隔离级别的全部细节，也能挡住绝大多数并发写入问题。参数上，days控制预计离店时间，deposit押金直接影响后续结算，两者都应从界面输入并做范围校验（天数 1～30，押金不低于零）。

3.2 退房结算与存储过程

退房比入住多一步算钱。计算规则通常在需求里写成：房费 = 实际住店天数 × 房价快照，超时按半天或全天加收（课设可简化为按自然日向上取整）。金额计算放 Java 里也能做，但放在存储过程里更能体现数据库课设的价值，而且能保证无论从哪个入口退房，算法一致。

-- 退房存储过程：算费、写账单、改房态、记日志，全部在一个事务内 CREATE PROCEDURE sp_CheckOut @CheckInId INT, @PayMethod NVARCHAR(20) AS BEGIN SET NOCOUNT ON; BEGIN TRY BEGIN TRANSACTION; DECLARE @RoomNo VARCHAR(10), @Price DECIMAL(10,2), @InTime DATETIME, @Days INT, @Total DECIMAL(10,2); SELECT @RoomNo = RoomNo, @Price = PriceSnapshot, @InTime = CheckInTime FROM CheckIn WHERE CheckInId = @CheckInId AND Status = 1; IF @RoomNo IS NULL BEGIN RAISERROR('入住单不存在或已退房', 16, 1); END -- 按自然日向上取整计费，最少一天 SET @Days = CASE WHEN DATEDIFF(DAY, @InTime, GETDATE()) = 0 THEN 1 ELSE DATEDIFF(DAY, @InTime, GETDATE()) END; SET @Total = @Days * @Price; -- 写账单 INSERT INTO Bill(CheckInId, RoomCharge, TotalAmount, PayMethod, PayTime) VALUES(@CheckInId, @Total, @Total, @PayMethod, GETDATE()); -- 更新入住单与房态：退房后房间转待清扫 UPDATE CheckIn SET Status = 2, RealOutTime = GETDATE() WHERE CheckInId = @CheckInId; UPDATE Room SET Status = 2 WHERE RoomNo = @RoomNo; -- 记操作日志 INSERT INTO OperateLog(ActionType, RoomNo, Detail, OperateTime) VALUES('CHECKOUT', @RoomNo, CONCAT('结算金额 ', @Total), GETDATE()); COMMIT TRANSACTION; END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION; THROW; END CATCH END

这个存储过程里有几处值得在文档里点明。@RoomNo IS NULL的判断替代了“先查再判空”的写法，因为SELECT未命中时变量保持 NULL，用它做哨兵最省事。房态改成 2（待清扫）而不是直接回 0，是因为现实中退房后房间要打扫，前台不能立刻再卖给下一位客人——这个细节很多课设漏掉，答辩时提一句就是加分项。Bill表不存明细而是存汇总，因为RoomCharge已由入住单快照推出，重复存明细反而容易出现两处不一致。

结算方式用@PayMethod参数传入，取值限定为“现金/刷卡/扫码”三类，界面上用下拉框而不是自由输入，否则日志里会出现各种写法导致统计困难。

3.3 查询与报表：几个真会用到 SQL 语句

课设文档里通常要贴几条“典型查询”，选那些既体现 SQL 能力又确实会被前台用到的。第一个是实时房态总览，按楼层和状态汇总：

-- 按楼层统计各状态房间数，前台看板直接用 SELECT FloorNo, SUM(CASE WHEN Status = 0 THEN 1 ELSE 0 END) AS 空闲, SUM(CASE WHEN Status = 1 THEN 1 ELSE 0 END) AS 已住, SUM(CASE WHEN Status = 2 THEN 1 ELSE 0 END) AS 待清扫, SUM(CASE WHEN Status = 3 THEN 1 ELSE 0 END) AS 维修 FROM Room GROUP BY FloorNo ORDER BY FloorNo;

第二个是当前在住客人清单，退房和查房都要用，注意用LEFT JOIN保证客人信息缺失时入住单仍能显示：

SELECT c.CheckInId, c.RoomNo, g.GuestName, g.Phone, c.CheckInTime, c.PlanOutTime, c.PriceSnapshot FROM CheckIn c LEFT JOIN Guest g ON c.GuestId = g.GuestId WHERE c.Status = 1 ORDER BY c.RoomNo;

第三个是营收统计，按日期汇总已结算账单，供课设里的“报表模块”使用：

SELECT CAST(PayTime AS DATE) AS 日期, COUNT(*) AS 单数, SUM(TotalAmount) AS 营收 FROM Bill WHERE PayTime BETWEEN @StartDate AND @EndDate GROUP BY CAST(PayTime AS DATE) ORDER BY 日期;

这三条覆盖了“状态聚合、多表关联、时间区间统计”三种典型场景，足够撑起文档里的 SQL 展示部分。写的时候记住：能用CASE WHEN做行列转换就别在 Java 里循环拼，导师看的是你 SQL 的熟练度。

4. Swing 界面与数据联动：桌面端怎么做得像回事

4.1 主界面布局与房态看板的实现思路

Swing 做管理系统的常见毛病是所有功能塞进一个 JFrame，用一堆 JButton 平铺，点击后弹新窗口。这种结构演示时窗口叠窗口，找不回主界面，观感很差。比较稳妥的结构是主窗口用JTabbedPane分页，或左侧JList做导航、右侧CardLayout切换内容面板。前者实现成本低，后者更像成品，课设按时间选。

房态看板是整个界面里最出彩的部分，用JPanel加GridLayout，每个房间是一个自定义小面板，颜色随房态变：

// 单个房态卡片：继承 JPanel，用背景色区分房态，点击触发操作 public class RoomCard extends JPanel { private final String roomNo; private int status; public RoomCard(String roomNo, int status) { this.roomNo = roomNo; this.status = status; setLayout(new BorderLayout()); setPreferredSize(new Dimension(90, 70)); setBorder(BorderFactory.createLineBorder(Color.GRAY)); JLabel label = new JLabel(roomNo, SwingConstants.CENTER); label.setFont(new Font("微软雅黑", Font.BOLD, 16)); add(label, BorderLayout.CENTER); applyStatusColor(); } // 房态配色集中在此方法，改配色只改一处 private void applyStatusColor() { switch (status) { case 0: setBackground(new Color(198, 239, 206)); break; // 空闲-浅绿 case 1: setBackground(new Color(255, 199, 206)); break; // 已住-浅红 case 2: setBackground(new Color(255, 235, 156)); break; // 待清扫-浅黄 case 3: setBackground(new Color(200, 200, 200)); break; // 维修-灰 default: setBackground(Color.WHITE); } repaint(); } public String getRoomNo() { return roomNo; } public void setStatus(int status) { this.status = status; applyStatusColor(); } }

配色方法集中在一处是关键。很多同学把颜色写死在各个刷新位置，后来想调整就显得很乱。构建看板时从数据库一次性查出所有房间，按RoomNo生成卡片放进网格，点击卡片时根据当前房态弹出不同操作对话框：空闲弹入住登记、已住弹退房结算、待清扫弹“清扫完成”。

4.2 前台登录与权限的最小实现

课设的权限不必做 RBAC 那一套，两个角色（管理员、前台）就够。SysUser表存用户名、密码哈希、角色、启用状态。登录时不要明文比对密码，至少做一次 MD5 加盐——这不是为了安全等级，而是让文档里“安全性设计”一节有话可说：

// 登录校验：密码加盐后取 MD5，与库中哈希比对 public boolean login(String username, char[] rawPassword) { String sql = "SELECT PasswordHash, Salt, Role FROM SysUser " + "WHERE UserName = ? AND Enabled = 1"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username); ResultSet rs = ps.executeQuery(); if (!rs.next()) return false; String stored = rs.getString("PasswordHash"); String salt = rs.getString("Salt"); String input = md5(new String(rawPassword) + salt); // 盐值与原文拼接再哈希 if (!stored.equalsIgnoreCase(input)) return false; Session.currentRole = rs.getString("Role"); // 简单会话变量，控制菜单可见性 return true; } catch (SQLException e) { throw new RuntimeException("登录异常", e); } }

Session.currentRole用静态变量存当前角色，是最省事的做法，适合单用户桌面程序。菜单构建时按角色过滤：前台看不到“用户管理”和“价格维护”。这套东西写进文档不超过半页，但能让“系统设计”章节看起来完整。密码输入框用JPasswordField，取到的是char[]，不要立刻toString()成 String 长期持有，用完及时清空——这是个小习惯，答辩时被问到可以答得很自然。

4.3 数据刷新与表格组件

所有业务操作完成后，界面必须刷新，否则会出现“库已改、界面没变”的假象。最简单的做法是每个功能面板提供一个refreshData()方法，入住、退房、换房成功后统一调用。表格用JTable+DefaultTableModel，数据从ResultSet逐行读入：

// 通用查询填充表格：列名来自 ResultSetMetaData，避免手写列顺序出错 public static void fillTable(DefaultTableModel model, ResultSet rs) throws SQLException { model.setRowCount(0); // 先清空旧数据 ResultSetMetaData meta = rs.getMetaData(); int cols = meta.getColumnCount(); while (rs.next()) { Object[] row = new Object[cols]; for (int i = 1; i <= cols; i++) row[i - 1] = rs.getObject(i); model.addRow(row); } }

列名可以在初始化DefaultTableModel时按meta.getColumnLabel(i)自动取，省去每张表手写一遍。注意model.setRowCount(0)不能漏，否则每次刷新都会追加重复行，这几乎是我见过频率最高的界面 bug。

数据库连接不要每次操作都新建，用一个简单的DBUtil持有Connection，或者用连接池（课设里手写一个极简的ArrayBlockingQueue连接池就足够，不必引入额外依赖）。连接串把encrypt=false之类的参数写在配置文件里，别硬编码到 Java 源码，改数据库地址时不用重新编译。

5. 常见问题排查：课设里最容易翻车的五个点

5.1 中文乱码：从连接串到排序规则

现象：界面显示房型名、客人姓名全是问号或方块；日志里写进去的中文变成乱码。原因通常有两层：一是 JDBC 连接串没指定字符集，二是数据库排序规则（Collation）不是中文兼容的。SQL Server 的字符串类型分VARCHAR（单字节）和NVARCHAR（Unicode），如果表字段用VARCHAR存中文，在非中文排序规则下就会丢字。

解决办法：中文列一律用NVARCHAR，Java 端PreparedStatement.setString会自动按 Unicode 传；连接串加上characterEncoding=UTF-8；建库时选中文排序规则（如Chinese_PRC_CI_AS）。已经建好的表可以用ALTER TABLE ... ALTER COLUMN改类型，但要注意索引和约束会受影响，课设阶段直接重建库更省事。

5.2 事务不回滚：自动提交没关或异常被吞

现象：入住时插入入住单成功，但更新房态那一步抛异常，结果房间还是空闲，入住单却已经存在。原因几乎总是setAutoCommit(false)之后，在 catch 里只打印了异常没调rollback()，或者把整个 try 包在另一个吞异常的方法里。

解决办法：统一按“关自动提交 → 业务操作 → commit → catch 中 rollback → finally 恢复并关闭”的骨架写，把这个骨架固化成模板方法。另外，try-with-resources关闭PreparedStatement没问题，但Connection一定要在 finally 里手动处理，不能一被关闭就丢失回滚机会。

5.3 房态并发更新：两个人同时点入住

现象：演示时开两个客户端，同时给 302 办入住，两条入住单都插进去了。原因是没有行锁，两个事务都读到 Status = 0，都判定可以入住。

解决办法：如 3.1 所示，在查询房态时加WITH (UPDLOCK, ROWLOCK)，更新时在 WHERE 里带Status = 0并检查影响行数。更稳妥的写法是把入住放到存储过程里，用SERIALIZABLE隔离级别或sp_getapplock对房号加应用锁。课设做到前两层就足够，第三层写在文档“并发控制设计”里当延伸。

5.4 金额精度：double 算钱算出 0.9999

现象：房费 199.9 元，两天算出 399.79999999999995。原因是 Java 里用double或float做金额运算。数据库端如果字段用FLOAT也会有同样问题。

解决办法：数据库金额列一律DECIMAL(10,2)，Java 端用BigDecimal做运算，setScale(2, RoundingMode.HALF_UP)统一保留两位。BigDecimal比较用compareTo而不是equals，因为equals会比较精度位数，1.0和1.00判不相等，这个坑很隐蔽。

5.5 界面卡死：数据库操作放到了事件线程

现象：查询大半年报表时界面白屏、按钮点不动。原因是 Swing 的事件分发线程（EDT）被阻塞了，所有界面重绘都在等你的 SQL 返回。

解决办法：耗时操作放进SwingWorker，doInBackground()里查库，done()里更新表格和提示。小数据量时看不出差别，但演示营业报表时这个细节非常加分，也是“系统性能设计”一节可以写的实打实内容。

6. 验收与答辩：怎么把这份方案讲成一套完整设计

答辩现场，导师通常先看运行效果，再翻文档，最后挑两三个点追问。顺序决定策略：演示要稳，文档要有结构，追问要接得住。

演示前先在干净环境里跑一遍建库脚本，确保从零建库到登录、入住、退房、报表一条龙无手工干预。演示路径固定成五步：登录（展示角色菜单差异）→ 房态看板（指着颜色说清四种状态）→ 办一次入住（当场刷新看板变红）→ 退房结算（展示生成的账单和待清扫状态）→ 营收报表（展示刚才那笔入账）。五步控制在三分钟内，中间不要打开代码编辑器。

文档结构按“需求分析 → 概念设计（E-R 图）→ 逻辑设计（表结构）→ 物理实现（约束、索引、存储过程）→ 功能实现（界面与关键代码）→ 测试与并发验证”组织，每张表后附字段说明表，每个存储过程后写调用示例。E-R 图里把客人、房间、入住单的关系画清楚，一对多、一对一不要画反。

被追问的高频点，提前准备答案：

还有一个小技巧：主动展示一次失败场景。比如把某张入住单的RealOutTime手动改成早于CheckInTime，让数据库的 CHECK 约束当场报错，然后解释“这就是为什么规则要写进数据库而不是只写在代码里”。这种自证式的演示，比任何口头说明都有说服力。

我自己的血泪经验是：每次答辩前必做一次“删库重建”，从脚本一路跑到演示结束，中间不允许有任何一步是手工补的。因为你在自己机器上跑得通，不代表换个环境就通——连接串、排序规则、初始账号，任何一处都可能让三分钟的演示卡在第一屏。这套流程走顺了，方案就算真的交付了。希望帮到你。

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