企业官网建设流程全解析

简介：Java实现的控制台公园售票管理系统，是一份适合Java初学者、课程设计或毕业设计参考的完整项目源码。系统采用命令行界面，围绕用户登录验证与票务信息管理，实现了增删改查等核心操作，并全面运用了面向对象设计、JDBC数据库连接、PreparedStatement防SQL注入、密码哈希存储、异常处理与日志记录等关键技术。资源包共23个文件，包含8个java源码、8个class编译文件、6个xml配置文件及1个iml项目文件，压缩包大小仅25KB，内含src源码目录与IDE工程配置，结构清晰，导入开发工具即可运行和调试。目前已有616人学习参考，尤其适合用来理解Java控制台应用开发、MVC分层架构及JUnit/TestNG测试实践。通过这份资源，读者能够系统掌握从用户认证到数据库操作的完整业务实现，快速迁移到类似票务管理或课程作业中，并为进一步扩展功能提供了清晰的基础代码，是一份实用且轻量的Java学习样例。

1. 控制台公园售票管理系统是Java基础最值得动手练的项目

Java实现控制台公园售票管理系统听起来像个课程设计，但认真把它做完就会发现，Java基础里面试里反复问的几个点都被它串起来了：面向对象建模、集合选型、文件读写、异常处理、接口解耦。用GUI或Web框架去做，界面很容易把业务逻辑的粗糙掩盖掉；换成控制台，用户每输入一次命令都要落到具体逻辑上，数据对不对、流程通不通、库存会不会超卖，全都会暴露出来。适合刚学完Java基础、想找第一个完整项目的人，也适合准备Java面试、想拿一个能讲清楚设计点的人。下面这套方案不假设有现成源码，按我日常开发会采用的可编译、可运行、可继续扩展的方式梳理一遍。

2. 控制台售票系统的数据建模：票种、订单与库存

公园售票首先要定义“票”。成人票、儿童票、学生票、老年票如果直接用字符串写在业务代码里，后面做价格计算、退票校验、统计报表时会到处出现字符串比较，改一个名字就得全项目替换。常见做法是把固定属性做成Java枚举，由枚举统一提供票种和基础价格的入口。

2.1 用枚举定义票种主数据

枚举在Java里天然适合表达固定分类。公园票种相对稳定，价格调整发生在配置层，可以把枚举当成“主数据表”来用，界面展示名和基础价格都放进去。

public enum TicketType { ADULT("成人票", 8000), CHILD("儿童票", 4000), STUDENT("学生票", 5000), OLD("老年票", 2000); private final String displayName; private final long priceFen; TicketType(String displayName, long priceFen) { this.displayName = displayName; this.priceFen = priceFen; } public String getDisplayName() { return displayName; } public long getPriceFen() { return priceFen; } }

这里刻意用“分”做金额单位，而不是double。Java基础题里经常问0.1 + 0.2为什么不等于0.3，如果售票系统直接用double存票价，累计报表时误差会被放大。用long存分，打印时再除以100，既比BigDecimal轻，也不会丢精度。displayName只给控制台展示用，不参与计算；getPriceFen()是后续所有价格运算的唯一入口，周末调价只需要在计算层做一件事，不需要到处找价格常量。

2.1.1 为什么不在枚举里放游玩日期

有些公园票会区分当日票和指定日期票，这个字段千万不要放进枚举。枚举擅长表达固定分类，日期是动态业务数据；同一票种在不同日期可能有不同价格，如果把日期和某种票绑定，就没法表达“周末成人票上浮”这类规则。正确的做法是让日期只出现在订单创建阶段，后面所有日期校验都在这里完成。

2.2 订单类：保存价格快照而不是引用商店价

售票系统最容易踩的坑是订单里的单价用了当前票价。如果枚举里的价格后来调了，历史订单的统计营收会跟着一起变，账目就对不上。所以订单要把下单时的票种、票名、单价都复制一份，成为不可变快照。

public class Order { private final String orderId; private final TicketType ticketType; private final String ticketName; // 下单时票名快照 private final long unitPriceFen; // 下单时单价快照 private final int quantity; private final long totalFen; private final LocalDate visitDate; private final LocalDateTime createTime; private final String customerPhone; private boolean refunded; public Order(String orderId, TicketType ticketType, String ticketName, long unitPriceFen, int quantity, LocalDate visitDate, LocalDateTime createTime, String customerPhone) { this.orderId = orderId; this.ticketType = ticketType; this.ticketName = ticketName; this.unitPriceFen = unitPriceFen; this.quantity = quantity; this.totalFen = unitPriceFen * quantity; this.visitDate = visitDate; this.createTime = createTime; this.customerPhone = customerPhone; } public void markRefunded() { this.refunded = true; } public boolean isRefunded() { return refunded; } // 其余 getter }

把unitPriceFen和ticketName直接复制进订单，是为了让订单成为一条独立的历史记录。即使后面枚举调价，老订单计算营收时仍然使用当时的价格。ticketType保留枚举类型，统计按票种分组时可以直接用groupingBy，不用再从字符串解析。refunded只打标记不删订单，这样退票记录会在数据文件里保留，方便后续对账。

2.3 内存“数据表”：集合类型怎么选

控制台版本可以不接数据库，但集合选型决定了代码能不能继续扩展。下面这张选型表可以直接用在设计说明里。

public class ParkTicketContext { private final Map<TicketType, AtomicInteger> stock = new EnumMap<>(TicketType.class); private final Map<String, Order> orders = new LinkedHashMap<>(); public ParkTicketContext() { for (TicketType type : TicketType.values()) { int init = switch (type) { case ADULT -> 500; case CHILD -> 200; case STUDENT -> 300; case OLD -> 100; }; stock.put(type, new AtomicInteger(init)); } } }

这里用了Java 14以后的switch表达式，如果项目还用JDK 8，改成普通switch赋值即可。初始库存放在构造器里而不是枚举里，是为了解耦“票种定义”和“库存配置”，将来从配置文件读库存时不需要改枚举。AtomicInteger在单线程中也能保证内存可见性，后续给售票逻辑加锁时，不再需要额外给库存字段加volatile。订单表用LinkedHashMap而不是HashMap，是因为控制台打印“全部订单”时，用户期望看到先买的排在前面，HashMap的遍历顺序不固定，排查问题时很难受。

3. 控制台交互层：菜单循环、输入校验与命令解析

控制台程序最常见的结构是“打印菜单、读命令、执行、回到菜单”。这个循环本身不难，但退出条件、输入异常、命令分发如果没有设计，后期每加一个功能都要动主循环。

3.1 主循环先想好退出条件

用户按Ctrl+C强退时，内存里的订单数据会全部丢光。我一般会在菜单里显式提供“0. 保存并退出”，并在run方法里统一处理异常，让程序在任何错误后都能回到菜单，而不是直接炸掉。

public class ConsoleRunner { private final ParkTicketService service; private final Scanner scanner = new Scanner(System.in); public ConsoleRunner(ParkTicketService service) { this.service = service; } public void run() { while (true) { printMenu(); System.out.print("请输入操作编号: "); String input = scanner.nextLine().trim(); if ("0".equals(input)) { service.saveAll(); System.out.println("数据已保存，再见。"); return; } try { dispatch(input); } catch (BusinessException e) { System.out.println("业务提示: " + e.getMessage()); } catch (Exception e) { System.out.println("系统异常: " + e.getMessage()); } } } }

这里用nextLine()而不是nextInt()，原因是在控制台菜单里，用户输入1后会按回车，nextInt()遇到非数字会抛异常且不消费错误输入，很容易把换行符留到下一次读取。统一用字符串读进来，到业务层再解析，输入处理只影响交互层，不会污染核心逻辑。return直接退出run方法，而不是用System.exit(0)，这样将来如果把这个Runner嵌进Spring Boot定时任务，不会把整个进程杀掉。BusinessException单独捕获，让用户看到的是“库存不足”而不是Exception in thread "main"。

3.2 输入校验：把“解析”和“业务”拆开

控制台项目的大量Bug不在业务，而是用户输入了-1、abc、2024-02-30。校验规则最好集中成一个工具类，避免每个菜单方法里都写一遍try/catch。

3.2.1 日期解析要避开默认的 SMART 模式

日期校验有个隐蔽的坑。DateTimeFormatter.ofPattern("yyyy-MM-dd")默认使用SMART解析，碰到2024-02-30会把日期静默修正为2024-02-29。售票系统里用户填错日期，系统却自动改掉，入园时会对不上。

public class InputParser { private static final DateTimeFormatter DATE_FORMAT = DateTimeFormatter.ofPattern("uuuu-MM-dd", Locale.CHINA) .withResolverStyle(ResolverStyle.STRICT); public static LocalDate parseVisitDate(String raw) { LocalDate date; try { date = LocalDate.parse(raw.trim(), DATE_FORMAT); } catch (DateTimeParseException e) { throw new BusinessException("日期格式错误，应该写成 2025-03-09"); } if (date.isBefore(LocalDate.now())) { throw new BusinessException("游玩日期不能早于今天"); } return date; } public static int parsePositiveInt(String raw, String fieldName) { int value; try { value = Integer.parseInt(raw.trim()); } catch (NumberFormatException e) { throw new BusinessException(fieldName + "必须是整数"); } if (value <= 0) { throw new BusinessException(fieldName + "必须大于0"); } return value; } }

withResolverStyle(ResolverStyle.STRICT)是强制严格解析，非法日期直接抛异常。uuuu和yyyy在严格模式下有区别，uuuu更适合公历日期处理，yyyy在公元前的场景才有问题，这里统一用uuuu更稳。parsePositiveInt里的判断顺序很重要：先用Integer.parseInt捕获非数字，再判断大于0；如果把raw.trim()解析出的负数直接丢给业务，后面的库存判断会出现负数扣减。

3.3 命令分发用 Map<接口>，不要用巨型 switch

菜单一多，if/else分发会让run方法越来越长。把每个菜单项封装成执行器，用Map建立编号到执行的映射，主循环就不用再改。

@FunctionalInterface interface Command { void execute(); } private final Map<String, Command> commands = new LinkedHashMap<>(); private void initCommands(ParkTicketService service) { commands.put("1", () -> sellTicketMenu()); commands.put("2", () -> refundTicketMenu()); commands.put("3", () -> dailyReportMenu()); commands.put("9", () -> printAllOrders()); }

Command是函数式接口，execute()不接收参数，具体需要的输入由菜单方法内部从Scanner读取。用LinkedHashMap是为了让菜单显示顺序和Map的put顺序一致。以后要加功能，只需要写一个方法，然后在initCommands里加一行put，不会再碰主循环代码。面试聊到扩展性时，这也是一个“开闭原则”的真实例子。

3.4 Windows 控制台中文乱码和编码设定

Java控制台项目在Windows上最常见的坑是中文乱码。问题根源是Scanner默认使用Charset.defaultCharset()，和系统码页不一致时读进来的中文会变成问号。在IDEA内置终端里一般不暴露，打包成jar双击运行时才出现。常规做法是启动命令里显式指定编码：java -Dfile.encoding=UTF-8 -jar park-ticket-system.jar。如果必须跑在GBK终端，就把Scanner和输出流的编码统一成System.console().charset()。JDK 18以后默认UTF-8，但老JDK还大量存在，这条建议值得写进README。

4. 售票、退票与统计：三个不能做错的核心动作

数据建模完成后，业务核心就是三个动作：售票、退票、统计。三个动作都不复杂，但顺序错了就会出现库存不一致和账目对不上。

4.1 售票流程：库存预检和价格计算放在同一把锁里

售票不是简单地if (库存 > 数量)再扣减。库存预检、生成订单、扣减库存要放在同一个同步代码块里，否则两个线程同时读到库存为5，各卖出5张时，系统会卖出10张。控制台系统虽然多数是单机单用户，但这个并发问题必须想清楚。

public Order sell(TicketType type, int quantity, LocalDate visitDate, String customerPhone) { if (quantity <= 0) { throw new BusinessException("购买数量必须大于0"); } synchronized (this) { AtomicInteger rest = stock.get(type); int current = rest.get(); if (current < quantity) { throw new BusinessException( type.getDisplayName() + "库存不足，当前剩 " + current + " 张"); } long unitPrice = calcPrice(type, visitDate); String orderId = genOrderId(); Order order = new Order(orderId, type, type.getDisplayName(), unitPrice, quantity, visitDate, LocalDateTime.now(), customerPhone); orders.put(orderId, order); rest.addAndGet(-quantity); return order; } }

genOrderId()一般用yyyyMMddHHmmss加三位自增序号，保证同一秒内的订单号不重复。synchronized(this)锁住整个售票流程，保证“检查库存、生成订单、扣库存”三步不可分割。关键是先创建订单再扣库存；如果订单创建过程中抛异常，代码不会走到addAndGet那一行，库存自然没有被改掉。calcPrice放在锁内执行，保证同一时刻价格规则基于相同的基础数据。

4.2 价格计算：周末上浮用方法而不是if

公园常见规则是周末成人票上浮。如果直接在sell方法里写if，将来又加夜场票、节假日票，业务方法会越来越长。把计价规则单独拆出来，至少可以让售票方法的逻辑不变。

private long calcPrice(TicketType type, LocalDate visitDate) { DayOfWeek dow = visitDate.getDayOfWeek(); boolean weekend = dow == DayOfWeek.SATURDAY || dow == DayOfWeek.SUNDAY; if (weekend) { return Math.round(type.getPriceFen() * 1.2); } return type.getPriceFen(); }

这里用Math.round把计算结果四舍五入到分。用long做金额时，遇到百分比调价会得到小数，必须明确取整规则。如果将来有更多价格策略，再把这个方法抽成PriceStrategy接口，每种策略只管自己的规则，调用处用策略链组合。控制台项目不必提前上设计模式，但计价规则已经出现明显if分支时，抽象边界就在这里。

4.3 退票流程：历史记录不能直接删除

退票比售票更敏感，涉及两件事：库存要回补，但订单不能从Map里删除。如果直接orders.remove(orderId)，当天统计就会少一笔，财务对不上。正确做法是继续保留订单，用一个refunded标记表示已退。

public void refund(String orderId) { Order order = orders.get(orderId); if (order == null) { throw new BusinessException("订单不存在，请检查订单号"); } synchronized (this) { if (order.isRefunded()) { throw new BusinessException("该订单已退票，不能重复操作"); } if (order.getVisitDate().isBefore(LocalDate.now())) { throw new BusinessException("游玩日期已过期，无法退票"); } stock.get(order.getTicketType()).addAndGet(order.getQuantity()); order.markRefunded(); } }

先查订单，再判断重复退票和过期，最后补库存。LocalDate.now()判断的是“游玩日期已经过去”的硬性条件；如果想限制当天开园后不能退，需要把判断改成LocalDateTime.now()去比较具体时间。这里和售票用同一把this锁，避免了“退票回补库存”和“售票扣减库存”交错执行，这是保证库存不超卖的关键。

4.4 日报统计：Stream聚合代替多个计数变量

日报要输出当天有效订单数、售出总张数、实际营收、各票种票数。用for循环也能做，但代码里会堆四五个临时变量；用Stream聚合更直白。

public DailyReport dailyReport(LocalDate date) { List<Order> valid = orders.values().stream() .filter(o -> o.getVisitDate().equals(date)) .filter(o -> !o.isRefunded()) .collect(Collectors.toList()); long ticketCount = valid.stream() .mapToLong(Order::getQuantity).sum(); long revenue = valid.stream() .mapToLong(o -> o.getUnitPriceFen() * o.getQuantity()).sum(); Map<TicketType, Long> byType = valid.stream() .collect(Collectors.groupingBy(Order::getTicketType, Collectors.summingLong(Order::getQuantity))); return new DailyReport(date, valid.size(), ticketCount, revenue, byType); }

filter筛出当天且未退票的订单；ticketCount是所有实际出票张数，不是订单数；revenue用单价快照乘以数量，再累加，不会因为枚举调价而波动。groupingBy(Order::getTicketType)把相同票种分到一组，summingLong(Order::getQuantity)作为下游收集器计算总张数。控制台输出时再按枚举声明顺序遍历byType，避免HashMap顺序不稳定。

4.5 CSV持久化：用纯文本而不是Java序列化

控制台程序关闭后订单要保留，最简单的做法是每次保存时把全量订单写成CSV。Java序列化虽然一行代码就能实现，但它和类版本强绑定，字段一变旧文件就坏；CSV文本能用Excel打开核对，更适合这种小系统。

public void saveOrdersToCsv(String path) throws IOException { try (BufferedWriter writer = Files.newBufferedWriter( Paths.get(path), StandardCharsets.UTF_8)) { writer.write("orderId,ticketType,ticketName,quantity,unitPriceFen,visitDate,isRefunded"); writer.newLine(); for (Order o : orders.values()) { String line = String.join(",", o.getOrderId(), o.getTicketType().name(), o.getTicketName(), String.valueOf(o.getQuantity()), String.valueOf(o.getUnitPriceFen()), o.getVisitDate().toString(), String.valueOf(o.isRefunded())); writer.write(line); writer.newLine(); } } }

CSV字段里如果有逗号，需要给字段加双引号并转义。这里订单表字段固定、没有逗号，用String.join最简单；如果将来加入自定义票种名称，就要提供escapeCsvField()做转义。try-with-resources会在方法结束或异常时自动关闭文件流，避免保存过程中断电导致文件损坏。加载时用Files.readAllLines逐行反向解析，表头或字段数不对的行直接跳过，并在控制台提示修复。

5. Java售票系统的异常处理与并发边界：能跑不代表不会崩

功能都跑通之后，离“能提交作业”还差一类工作：异常处理和并发边界。这部分最容易被忽略，也是面试时拉开差距的地方。

5.1 业务异常和系统异常分开处理

控制台售票系统最怕用户输入一个错误字符串，程序就抛出一整段堆栈。更合理的是定义业务异常，让错误提示保持稳定。

public class BusinessException extends RuntimeException { public BusinessException(String message) { super(message); } }

RuntimeException不需要在方法签名上声明throws，可以让命令分发层只捕获少数几个类型。业务异常代表“票卖完、日期过期、订单不存在”这类用户操作错误；系统异常代表文件读写失败、代码Bug。控制台主循环里分别捕获，用户看到的是可读的提示，开发者在日志里才能看到堆栈。

5.2 synchronized 的锁粒度：从对象锁到票种锁

前面售票和退票用的都是synchronized(this)，锁的是整个服务对象。如果同时卖成人票和儿童票，两笔订单也会互相等待。控制台单用户场景下无所谓，但面试官会问能不能并发卖不同票种。

private final Map<TicketType, Object> typeLocks = new EnumMap<>(TicketType.class); // 初始化：给每个票种一个独立的锁对象 public Order sellByTypeLock(TicketType type, int quantity, LocalDate date) { synchronized (typeLocks.get(type)) { // 同一票种的库存检查、订单生成、库存扣减 } }

按票种加锁后，成人票和儿童票可以同时卖，并发度更高。代价是代码里多维护一个EnumMap，而且订单Map本身需要并发安全。如果只用synchronized(this)，订单写入自然安全；拆成票种锁后，orders要用ConcurrentHashMap或者单独加锁，否则两个线程同时写入不同票种订单时，LinkedHashMap内部结构会被破坏。对我的项目来说，控制台版本用全局锁更稳妥，按票种锁可以作为优化方向写进设计文档。

5.3 金额单位统一用分，打印时再转换

用long存分已经避开了double误差，但统计和打印层还会出现把分转成元的操作。这个转换一定要集中在工具方法里，不要散落在各个菜单中。

public static String fenToYuan(long fen) { return String.format("%.2f", fen / 100.0); }

fen / 100.0保留小数点，String.format统一输出两位。如果某个地方手滑用了fen / 100整数除法，金额会直接抹掉角分。把转换集中在一个方法里，至少能减少这类低级错误。营收统计里unitPriceFen * quantity使用long，单日几万张票不会溢出；要警惕的是某些报表把“元”转成“万元”时，除以10000的舍入规则要写清楚。

5.4 边界条件：空订单表、负数数量、库存为0

控制台系统容易崩的场景往往不是复杂逻辑，而是边界值。建议在代码里至少覆盖以下用例。

这些用例可以直接写成JUnit测试，也可以先用手工测试过一遍。控制台程序最怕用户输入一个边缘值就把整段流程打乱，把边界条件列出来，至少心里有底。

6. 把控制台售票系统改成可测试的小框架：依赖注入与单元测试

6.1 核心服务不依赖 Scanner

如果ParkTicketService里直接写了new Scanner(System.in)，单测时就得模拟键盘输入，很痛苦。常见做法是核心服务只接收方法参数，返回结果或抛异常；ConsoleRunner负责收集键盘输入并调用核心服务，这样核心业务保持纯Java，不依赖控制台环境。

public class ParkTicketService { private final Map<TicketType, AtomicInteger> stock; private final Map<String, Order> orders = new LinkedHashMap<>(); public Order sell(TicketType type, int quantity, LocalDate visitDate, String phone) { // 纯业务逻辑 } }

测试代码可以直接new ParkTicketService()，调用sell()和refund()，不再需要准备InputStream。这也是依赖倒置在控制台项目里的最小体现：高层模块只依赖service的方法，不依赖具体输入源。

6.2 用 JUnit 5 做售票与退票回归测试

单测不需要覆盖所有菜单，重点覆盖“退票后库存回补”和“日期早于今天报错”这两个核心不变式。

class ParkTicketServiceTest { private ParkTicketService service; @BeforeEach void setup() { service = new ParkTicketService(); } @Test void 退票后库存应当回补() { Order order = service.sell(TicketType.ADULT, 3, LocalDate.now().plusDays(1), "13800000000"); service.refund(order.getOrderId()); assertEquals(500, service.getStock(TicketType.ADULT)); assertTrue(order.isRefunded()); } @Test void 订票日期早于今天应当报错() { LocalDate past = LocalDate.now().minusDays(1); assertThrows(BusinessException.class, () -> service.sell(TicketType.ADULT, 1, past, "13800000000")); } }

@BeforeEach每次测试都新建一个service，避免用例之间共享库存状态。第一个用例验证库存从初始值扣掉3，退票后又回到500；第二个用例验证日期校验会在订单生成之前拦截。当以后改动价格策略或退票规则时，这两个测试能在几秒内告诉我是否破坏了原有约定。

6.3 小扩展：近7天售票柱状图

在收尾阶段可以加一个不破坏结构的小功能：打印最近7天各天的售票总量，用#号画简单控制台柱状图。

public void printLast7Days() { for (int i = 6; i >= 0; i--) { LocalDate day = LocalDate.now().minusDays(i); long cnt = orders.values().stream() .filter(o -> o.getVisitDate().equals(day)) .filter(o -> !o.isRefunded()) .mapToLong(Order::getQuantity).sum(); System.out.printf("%s | %s (%d张)%n", day, "#".repeat((int) Math.min(cnt, 50)), cnt); } }

"#".repeat是Java 11才有的方法，老JDK可以用循环拼接字符串。图表上限截断到50个#，避免某天大销量撑爆控制台宽度。这个扩展只用现有orders容器做聚合，没有改动ParkTicketService的售票和退票方法，如果你在答辩时被问到“系统能不能再加一个功能”，这就是一个现成的扩展性示例。

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