企业官网建设流程全解析

简介：一套完整的JAVA课程设计报告，以ATM柜员机模拟系统为开发对象，面向正在学习Java面向对象编程与Swing界面开发的高校学生，可作为课程设计或自学练手的参考范本。资源包仅含1个docx文档，大小1.21MB，尽管体量精简，但内容完整覆盖需求分析、界面设计、功能实现与项目总结全流程，并附有存钱取钱核心代码、逻辑校验思路及SQL语句示例，方便读者按章节对照学习。已有387人学习下载，适合希望快速掌握ATM模拟系统开发框架、理解账户查询/存款/取款/改密等业务逻辑，并规范撰写课程设计报告的读者。通过该文档，读者既能对照梳理自己的代码结构，也能学习如何将面向对象设计、异常处理与数据库操作融入实际项目，同时了解窗口切换、用户登录验证等功能模块的搭建方法，有效提升Java综合应用能力。

1. 一个能跑完整个业务闭环的JAVA课设：ATM柜员机模拟系统到底在练什么

ATM柜员机模拟系统，这个名字在JAVA课程设计里出现频率极高，但它不是那种「交个作业就完事」的玩具项目。它把登录、查询、存款、取款、转账、改密六个完整业务串在一条链路上，前端是Swing图形界面，后端走数据库真实读写。也就是说，做完这个系统，你等于亲手走了一遍「界面层—业务层—持久层」的完整开发流程。对于刚接触Java面向对象、还没碰过GUI开发的同学来说，这份资源最值钱的地方不是代码本身，而是它把「一个软件怎么从需求变成可运行的程序」这个黑匣子拆开了。适合两类人：一类是正在做课设、需要参考完整实现的学生；另一类是准备面试、想快速回顾Swing和MyBatis配合方式的开发者。

2. 需求与模块边界：登录、查询、存取款、改密六条主线的功能拆解

课程设计的报告里，需求分析往往是最容易被跳过的一章，但恰恰是它决定了系统做出来是「能演示」还是「能答辩」。这份ATM柜员机模拟系统的需求写得比较清晰，六大功能模块边界明确：登录、账户查询、存款、取款、改密、退出。拆开看，每一条都可以对应到具体的类、方法和数据库操作。

2.1 功能清单与优先级排序

先理清功能边界。登录是入口，没有登录成功，其他所有界面都不应该可达；查询是最简单的只读操作，适合作为第一个实现的模块；存款和取款是核心业务，涉及金额变更和校验逻辑；改密涉及新旧密码校验；退出则是把状态清空、回到登录界面。

功能模块与实现要点的对应关系大致是这样：

从这里可以看出，六个功能实际上是三类操作的变种：查询类（只读）、变更类（金额增减）、更新类（密码替换）。我在做类似项目的时候，会先把这三类抽成三个公共服务方法，而不是一个功能一个方法硬写。原代码里的HandleServiceImpl就是这种思路——addMoney处理存款和转账增加，minusMoney处理取款和转账扣减，逻辑复用度高。

2.2 重难点分析：界面、数据持久化与异常处理

报告里列了七个重难点，实际编码时真正卡人的是三个：Swing布局与事件处理、数据持久化方式、异常处理覆盖范围。

Swing的难点在于它不像Web前端那样有CSS控制布局，所有组件都要手动setLocation和setSize。原代码里可以明显看到这一点，每个JLabel、JTextField、JButton都是先设定位置再设定尺寸，最后统一add到面板上。这种绝对定位方式写起来繁琐，但好处是界面效果可控，不会因为窗口缩放导致组件乱跑。如果你是第一次写Swing，建议先画一张草图，标注每个组件的x、y坐标，再动手写代码，能少调半天布局。

数据持久化这块，常见做法是两种：文件存储和数据库。原项目用的是MySQL + MyBatis，属于正经的数据库方案。文件存储（比如序列化成文本）虽然代码量小，但课设答辩时容易被追问「数据存在哪、怎么保证一致性」，不如数据库方案好解释。至于异常处理，原代码主要在业务层做了空值和格式校验，界面层用JOptionPane弹窗提示，这种分层处理是合理做法。

提示：功能图里画的模块划分，实际对应的是界面跳转关系，不是类继承关系。写代码时不要被图误导，Swing界面之间用CardLayout切屏，业务逻辑独立到Service层，各管各的。

这一条主线捋下来，你会发现整个系统的技术栈并不复杂：Swing画界面、MyBatis操作数据库、Service处理业务规则。真正的难点在「界面事件如何正确触达数据库」，也就是第3章要讲的窗口切换和第4章要讲的业务实现。

3. Swing界面与CardLayout：从登录窗口到五个功能面板的切换实现

界面设计这一章，核心不是「怎么把界面画好看」，而是「多个窗口之间怎么切换」。原项目用的是1个主窗口 + 5个功能窗口的结构，主窗口放菜单按钮，点击后跳转到对应功能界面。这个场景用CardLayout最合适，它是Swing里专门做多面板切换的布局管理器，所有面板叠在一起，通过show()方法控制显示哪一张。

3.1 窗口切换：CardLayout配合按钮事件

先说结构。常见做法是在主窗口创建一个JPanel作为容器，给它设置成CardLayout，然后把登录面板、菜单面板、查询面板、存款面板、取款面板、转账面板、改密面板全部add进去，每个面板给一个字符串标识。切换的时候只要调用：

CardLayout cardLayout = (CardLayout) contentPane.getLayout(); cardLayout.show(contentPane, "菜单");

这行代码的含义是：从当前面板切换到名为「菜单」的面板。第一次看这段代码的人容易懵的是contentPane.getLayout()这步——它先拿到容器现有的布局管理器，强转成CardLayout，然后才能调show()。如果容器压根没设置过CardLayout，这行会直接抛ClassCastException。

原代码里，每个功能面板的「返回」按钮都有这样一串动作：

mainView.setTitle("菜单"); cardLayout.show(contentPane,"菜单"); moneyText.setText("");

前两行是切换界面，第三行是清空输入框。这里有个很容易忽略的细节：每次返回菜单时把输入框清空。如果不清空，下一次进入存款界面，上次输入的金额还留在文本框里，用户点了「存入」，就会把旧数据再提交一次，这在演示场景里非常尴尬。

参数说明：show(Container parent, String name)的第一个参数是卡片所在容器，第二个参数是add()时指定的约束字符串，必须完全一致，多一个空格都匹配不上。

3.2 登录界面与主菜单：输入校验与页面跳转

登录界面是最先展示的窗口，它的逻辑是：用户输入卡号和密码，点击登录后，系统拿这两个值和数据库里的tb_user表比对。登录成功后，界面跳转到主菜单；失败则弹窗提示。

这里原代码没有展开，我按最常见的实现补全一下思路。登录按钮的事件里通常会做这几件事：

loginButton.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { String cardId = cardText.getText().trim(); String password = pwdText.getText().trim(); if (cardId.isEmpty() || password.isEmpty()) { JOptionPane.showMessageDialog(frame, "卡号和密码不能为空", "提示", JOptionPane.WARNING_MESSAGE); return; } User user = userService.login(cardId, password); if (user != null) { mainView.currentId = user.getId(); cardLayout.show(contentPane, "菜单"); } else { JOptionPane.showMessageDialog(frame, "卡号或密码错误", "提示", JOptionPane.ERROR_MESSAGE); } } });

这段代码的逻辑说明：trim()去掉首尾空格，避免用户手误多打了空格导致比对失败；currentId是MainView里一个用来记录当前登录用户ID的字段，后续所有查询、存款、取款操作都靠它定位用户；登录成功后用cardLayout.show切到菜单面板。

参数说明：JOptionPane.showMessageDialog的四个参数分别是父窗口、提示文案、标题、消息类型。消息类型有WARNING_MESSAGE、ERROR_MESSAGE、INFORMATION_MESSAGE三种，按场景选，答辩时老师喜欢问这个。

登录成功的前提是数据库里有预设用户。因为这是模拟系统，不提供注册功能，所以必须在数据库初始化脚本里预置几条用户数据，比如卡号1001、密码123456、余额5000.00这样的测试账号。很多同学在演示时栽跟头，就是因为数据库里没有预置数据，登录永远失败。

3.3 功能面板的布局设计：绝对定位与图片背景

原代码的功能面板有个很显眼的地方——构造函数里设置了一行：

setLayout(null);

这是Swing里最原始的布局方式，彻底放弃布局管理器，所有组件全靠手动定位。setLayout(null)之后，组件的位置和大小都交给setLocation和setSize控制。原代码里每个JLabel都先setLocation(0, 30)再setSize(700, 50)，这种写法看着啰嗦，但其实是模拟ATM机界面时最稳定的方案，因为ATM机界面元素本来就固定，不需要响应式调整。

图片背景的处理则是重写了paintComponent方法：

@Override protected void paintComponent(Graphics g) { super.paintComponent(g); if (backgroundImage != null) { g.drawImage(backgroundImage, 0, 0, getWidth(), getHeight(), this); } }

这段代码的作用是：每当面板需要重绘时，先把背景图片画满整个面板，再画其他组件。getWidth()和getHeight()是面板当前的实际宽高，图片会拉伸填满。注意这里有个坑：背景图用的是一张gif动图，ImageIcon加载动图时，只有第一帧会被画出来，动效是看不到的。如果你想让背景真正动起来，得用Timer逐帧刷新，但课程设计场景下静态背景完全够用，别在这上面浪费时间。

界面布局的另一个细节是字体设置。原代码反复使用new Font("黑体", Font.BOLD, 30)，这是为了在较大分辨率下让界面文字清晰可见。如果是在没有中文字体的系统上跑，Swing会回退到默认字体，中文可能显示成方块。这个在后面避坑章会详细讲。

这一章的核心结论是：Swing的多窗口项目，用CardLayout做主切换、绝对定位做子面板布局，是一套成熟且容易讲解的方案。你不需要学很炫的布局技巧，把这两招用熟，界面层就能撑起整个项目。

4. 存取款核心逻辑：按钮事件、金额校验与MyBatis数据库更新

第3章把界面层讲透了，这一章进入真正的业务核心——存取款。原代码里最有价值的部分也在这里：一个ChangeMoneyPanel类同时处理存款和取款两种场景，通过构造函数传入的type参数区分；业务层addMoney和minusMoney分别实现金额增加和扣减；持久层用MyBatis的动态SQL完成数据库更新。三层各司其职，代码结构值得细读。

4.1 存取款面板：ChangeMoneyPanel复用一个类实现两个功能

先看界面层的复用设计。构造函数签名是：

public ChangeMoneyPanel(String type, Container contentPane, CardLayout cardLayout, MainView mainView)

type参数只有两个取值：「存入」和「取款」。构造函数里有一行很关键：

final String substring = type.substring(0, 1);

这是取出type的第一个字，也就是「存」或者「取」。后面所有提示语都用这个substring拼接，于是同一个类自动适配了两种场景——输入「存入」时提示「请输入存款金额」，输入「取款」时提示「请输入取款金额」。

按钮事件里也是靠type.equals("存入")来分流的：

enterButton.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { if(type.equals("存入")){ HandleServiceImpl handleService = new HandleServiceImpl(); Result<Boolean> booleanResult = handleService.addMoney(mainView.currentId, moneyText.getText().trim()); JOptionPane.showMessageDialog(mainView, booleanResult.massage, "提示", JOptionPane.INFORMATION_MESSAGE); if(booleanResult.data){ backButton.doClick(); } }else{ HandleServiceImpl handleService = new HandleServiceImpl(); Result<Boolean> booleanResult = handleService.minusMoney(mainView.currentId, moneyText.getText().trim()); JOptionPane.showMessageDialog(mainView, booleanResult.massage, "提示", JOptionPane.INFORMATION_MESSAGE); if(booleanResult.data){ backButton.doClick(); } } } });

逻辑说明：点击按钮后，调用handleService对应的业务方法，传入当前登录用户的ID和文本框里输入的金额。业务方法返回一个Result<Boolean>对象，里面封装了操作是否成功的标记data和提示信息massage。弹窗展示提示后，如果操作成功，就模拟点击「返回」按钮回到菜单。这种「成功自动返回」的设计很符合ATM机的真实使用逻辑——存完钱退到主界面，而不是停在原界面等用户手动返回。

参数说明：moneyText.getText().trim()拿到的是用户输入的原始字符串，trim()去掉两端的空格。注意这里传的是String，真正的类型转换和校验发生在Service层，界面层不做任何业务判断。这是MVC分层的好习惯，界面只负责收集和展示，业务规则归Service管。

4.2 金额校验：空值、非法字符、整百限制

业务层的校验逻辑是这一段代码的精髓，完整拆开看：

@Override public Result<Boolean> addMoney(Long id, String money) { if (money.equals("")){ return new Result<Boolean>("不能为空",false); } if(!StringUtils.isStrictlyNumeric(money)){ return new Result<Boolean>("含有非法字符",false); } if(Double.parseDouble(money)%100!=0){ return new Result<Boolean>("ATM 中只支持百元大钞，零钱请前往柜台领取",false); } SqlSession sqlSession = sqlSessionFactory.openSession(); MysqlOperateMapper userMapper = sqlSession.getMapper(MysqlOperateMapper.class); userMapper.addMoneyById(id,new BigDecimal(money)); sqlSession.commit(); sqlSession.close(); return new Result<Boolean>("存款成功",true); }

三个if判断对应三个异常场景，我逐条说明：

第一个if判断money.equals("")，捕获的是空输入。用户在界面里什么都没敲就点了确认，getText()返回空字符串，直接提示「不能为空」。这里有个隐藏细节，money在调用前已经过了trim()，所以全空格输入也在这里被拦截了。

第二个if判断StringUtils.isStrictlyNumeric(money)，这个方法来自org.apache.commons.lang3.StringUtils，作用是判断字符串是否全部由数字组成。它不认小数点、不认正负号、不认空格。所以「12.5」「-100」「1 00」都会被拦下来，提示「含有非法字符」。这一步把绝大多数脏数据挡在门外。

第三个if是业务规则：Double.parseDouble(money)%100!=0。ATM机取款通常只支持百元面额，所以金额必须是100的倍数。这里用Double.parseDouble把字符串转成double，再取模判断。注意：能被100整除的，余数一定是0，所以取反就是「不是整百」就拒绝。

关于校验顺序，这三个if的顺序是有讲究的。先查空，再查格式，最后查业务规则。如果把第三个if放前面，用户输入「abc」时，Double.parseDouble("abc")直接抛NumberFormatException，程序就崩了。校验顺序错了，代码写得再好也白搭。

数据库操作部分是标准的MyBatis使用流程：

SqlSession sqlSession = sqlSessionFactory.openSession(); MysqlOperateMapper userMapper = sqlSession.getMapper(MysqlOperateMapper.class); userMapper.addMoneyById(id,new BigDecimal(money)); sqlSession.commit(); sqlSession.close();

这四行里最重要的一行是sqlSession.commit()。MyBatis的openSession()默认不自动提交事务，如果不手动commit，数据变更不会生效。很多同学跑完程序发现余额没变，第一个排查点就是这里——是不是忘了commit。最后一行close()释放连接资源，如果不关，连接池很快耗尽，系统运行一段时间后就会卡死。

minusMoney（取款）的逻辑和存款基本对称，多了一个余额检查：

User user = userMapper.selectById(id); if(user.getMoney().compareTo(new BigDecimal(money))<0){ return new Result<Boolean>("余额不足",false); }

这里用的是BigDecimal.compareTo而不是equals，原因是BigDecimal的equals方法要求精度也一致，1.0和1.00用equals比较会返回false，但用compareTo就只看数值大小。实际开发中，金额比较一律用compareTo，这是写财务相关代码的基本常识。

4.3 SQL映射与事务提交

持久层的SQL写在MyBatis的XML映射文件里，原代码给了两个最关键的操作：

<update id="addMoneyById"> update tb_user set money=money+#{money} where id =#{id} </update> <update id="minusMoneyById"> update tb_user set money=money-#{money} where id =#{id} </update>

这两个SQL的核心技巧是：金额更新用「相对更新」而不是「绝对更新」。money=money+#{money}是在原有余额基础上做加法，先查询余额再算出新余额然后更新，而是一条SQL直接在数据库端完成运算。这样做的好处有两个：一是减少了一次查询的IO开销；二是避免了并发场景下的数据覆盖问题——假设账户余额1000，同时在两个窗口分别取100和200，如果用先查后更新的思路，两个操作都读到1000，最后结果可能只剩800，而用相对更新，数据库串行执行两条SQL，结果一定是700。

参数说明：#{money}和#{id}是MyBatis的预编译参数，对应方法传入的BigDecimal money和Long id。预编译能防SQL注入——用户输入100; DROP TABLE tb_user这种恶意字符串时，预编译把它当成纯数据而不是SQL语句的一部分。做金融模拟系统，这个是必须有的安全底线。

事务层面，SQL是放在Service方法里执行的，也就是每执行一次存取款，开一个SqlSession，提交后关闭。这个写法在单用户场景没问题，但如果未来改造成多用户并发,建议把事务提升到Service层统一管理。课程设计阶段，保持现状就够。

这一章看下来，存取款功能的完整链路是：界面层收集输入 → Service层三重校验 → Mapper层相对更新SQL → 提交关闭Session。每一层职责单一，任何一步失败都能在界面弹窗给到明确提示。这个分层模型，是你答辩时讲「系统设计」的最佳素材。

5. 常见问题与避坑：课设提交前最容易翻车的五个点

这一章我从实际拆过的同类项目里，挑出五个高频故障记录给你。每一条都是真实会发生的场景，按「现象 → 原因 → 解决」写清楚。

5.1 登录按钮点了没反应，控制台报NullPointerException

现象：界面正常显示，输入卡号和密码，点登录按钮，界面没跳转，控制台输出一串NullPointerException。

原因：最常见的是cardLayout或contentPane变量为null。写界面代码时，如果CardLayout对象是在某个方法里创建的局部变量，而按钮事件里又引用这个变量，方法执行完变量就被回收了，事件触发时找不到对象。

解决：把CardLayout和主容器定义为Window类（比如MainView）的成员变量，在构造函数里实例化，所有内部类的事件处理器通过外层类.变量名访问。我一般会写MainView.this.cardLayout显式指定，避免内部类里同名变量遮挡。

5.2 运行报错「ClassNotFoundException: com.mysql.cj.jdbc.Driver」

现象：程序一启动就连不上数据库，报找不到JDBC驱动类。

原因：两个常见诱因。一个是项目里没引入MySQL驱动jar包——用Maven的话是漏了mysql-connector-java依赖，用IDEA直接开发的话是遗漏了jar包到lib目录；另一个是MySQL 8.x的驱动类名和5.x不一样，8.x要用com.mysql.cj.jdbc.Driver，5.x才用com.mysql.jdbc.Driver。

解决：如果你用的是MySQL 8.x，在pom.xml里加：

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>

同时检查连接串，加serverTimezone=Asia/Shanghai参数，不然MySQL 8.x会报时区错误。一个典型的连接串是：

jdbc:mysql://localhost:3306/atm_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8

5.3 存了1000元，余额显示只多了10.0

现象：输入1000点存入，提示成功，查询余额时数字不对，小数点位置诡异。

原因：类型不一致导致的精度丢失。界面输入是String，业务层先Double.parseDouble转成double，数据库映射时又转成BigDecimal。double本身就是二进制浮点，1000.0的二进制表示不是精确的，转成BigDecimal后可能得到999.99999999之类的值。原代码里存款方法在校验时用了Double.parseDouble，但真正写入数据库时用的是new BigDecimal(money)——这里money是原始字符串，所以写入数据库的其实是精确的1000，但如果哪一步把double的值传给数据库，精度就丢了。

解决：持久层统一用BigDecimal，字符串直接new BigDecimal(money)传入，绝不要经过double中转。校验时可以用Integer.parseInt或者先判断是不是整数再做整除判断，避免double误差。这是金融系统的基本红线，课设阶段养成好习惯，后面做正式项目就少填一个坑。

5.4 取款后余额没变，但提示「取款成功」

现象：取款500提示成功，回菜单查余额，发现一分没扣。

原因：看一下minusMoney方法里有没有sqlSession.commit()。MyBatis默认openSession()开的是非自动提交事务，执行完UPDATE后必须手动提交。如果只在addMoney里写了commit，minusMoney里漏了，存款生效取款不生效。

解决：在两个方法里都补上sqlSession.commit()并把sqlSession.close()放进finally块，或者直接用MyBatis的工具类让SqlSession自动管理事务。逻辑说明：finally里close()能保证即使前面的代码抛异常，数据库连接也能被释放，不会造成连接泄漏。

5.5 中文界面全部变成方块乱码

现象：界面标题、按钮、提示文字全是「口口口」这种方块。

原因：Swing默认字体不含中文字形，而原代码里字体设为「黑体」，如果运行环境没装中文字库，就回退失败。这是国产Java课设最常见的玄学问题，平时在Windows上跑得好好的，换到某些精简版Linux服务器上就翻车。

解决：字体配置改成兼容性更好的写法，优先检测系统可用中文字体：

Font font = new Font("Microsoft YaHei", Font.BOLD, 30);

如果还是乱码，检查启动时有没有加上文件编码参数：

java -Dfile.encoding=UTF-8 -jar atm_system.jar

-Dfile.encoding=UTF-8强制JVM用UTF-8读取源文件和资源，能在这个场景下兜底解决绝大多数乱码。

提示：数据库那边也别忘。如果建表用了utf8mb4，而JDBC连接串里没写characterEncoding=utf8，MySQL返回的数据到Java里同样会乱码。连接串、源文件编码、数据库编码三处必须保持一致。

这五个坑，前两个属于环境问题，后三个属于编码习惯问题。它们共同的特点是：报错信息不一定直观，排查起来费时间。把这条清单截图存在手机里，课设提交前对照检查一遍，能少熬两个通宵。

6. 进阶打磨：从演示级代码变成能过评审的完整项目

如果只是把原代码跑通，课设能及格，但答辩时老师会追问很多「为什么」。这一章我按自己拆项目的习惯，给你三条进阶改造路线，做完之后，你的系统就不是「能演示」，而是「能讲清楚」。

第一条是加密存储。原项目的密码在数据库里是明文，答辩时老师大概率会问「密码安全吗」。你可以引入MessageDigest做SHA-256哈希，登录时比对密文而不是明文：

public static String toSHA256(String input) { try { MessageDigest md = MessageDigest.getInstance("SHA-256"); byte[] hash = md.digest(input.getBytes(StandardCharsets.UTF_8)); StringBuilder sb = new StringBuilder(); for (byte b : hash) { sb.append(String.format("%02x", b)); } return sb.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException("SHA-256算法不可用", e); } }

逻辑说明：MessageDigest.getInstance("SHA-256")拿到算法实例，digest()做哈希运算得到字节数组，再逐字节转成十六进制字符串。这样数据库里存的是哈希值，即使库被拖走，密码也不会直接暴露。

第二条是操作日志。原代码做了存取款、改密的操作记录，但没有落库。你可以加一张tb_record表，字段包含user_id、operation_type、amount、operate_time，每次业务成功后插入一条记录。这样「查看交易记录」功能才有数据支撑，系统的业务闭环才算完整。

第三条是统一异常处理。现在每个方法里都有if判断+弹窗，代码重复率高。你可以封装一个业务异常类BizException，Service层只抛异常不处理，界面层统一捕获弹窗。改造后业务方法从十行变三行，代码好看很多，答辩时还能提「我用的是统一异常处理机制」，这是一个很好的加分印象点。

说到验证方法，我的习惯是每次改完代码，强制跑一遍「开户登录 → 查询余额 → 存取款 → 改密 → 退出再登录」的完整链路，确认每一步的数据库结果都正确。从那以后，我每拿到一份JAVA课程设计的代码，都会第一时间把数据库脚本和驱动版本先匹配上，再开始看业务代码——这个习惯帮我省掉了不知道多少「明明代码没问题却跑不起来」的深夜。希望帮到你。

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