2. 项目概述与整体设计思路

2.1 项目概述

最近有个刚学完JavaSE基础的同学问我：不借助Spring Boot、不连MySQL，能不能用纯Java写出一套能跑通的“后端管理系统”？于是我用一个“淘宝风卖鞋后台”的项目做了次完整验证。这套系统本质上是一个基于JavaSE（Java Standard Edition）实现的传统单体业务管理系统，覆盖了商品维护、用户管理、订单流转、库存变动、登录鉴权这些电商后台最常见的业务场景，核心目标是把Java基础语法、面向对象设计、集合框架、I/O流、异常处理、多线程等知识点真正串起来，而不是只停留在“能写练习题”的水平。

整个系统不需要安装任何数据库和服务中间件，数据落地用文件存储完成，启动入口就是一个main方法。但这不代表它是一个玩具项目——分层架构、接口设计、数据校验、幂等控制、扩展预留这些工程化设计思路全部保留。如果你正在学JavaSE，或者刚学完想找一个能放进简历的练手项目，这个选题非常适合你。

2.2 为什么选纯JavaSE，而不是直接上框架

很多初学者会有个误区：既然Spring Boot + MySQL已经是行业标配，为什么还要回头写纯JavaSE管理系统？这个问题我在很多场合被问过，我的回答一直很直接：框架帮你解决的是“接入问题”，但解决不了“理解问题”。

先说结论：纯JavaSE能让你看到一切底层运转逻辑。举几个例子，你用Spring Boot的时候，Service里加个@Transactional注解事务就生效了，但你知道底层是怎么判断连接是否需要回滚的吗？你用MyBatis的时候，Mapper接口没有实现类就能被注入，但你知道JDK动态代理在背后干了什么吗？如果你没写过纯Java的事务控制、没手写过数据访问层，这些框架的“魔法”对你来说就是黑盒。

在卖鞋管理系统的场景里，我刻意用文件存储代替数据库，用自定义Controller代替SpringMVC，用工厂模式手动管理对象创建。这样做的目的有三个：

1. 让数据流转过程完全透明：从用户输入到业务处理再到数据落地，每一步都是可见的代码。
2. 逼着你思考数据结构和算法边界：比如同样是查订单，用ArrayList遍历和用HashMap按订单号索引，性能差距在数据量上来以后非常明显。
3. 降低项目搭建门槛：不依赖Maven仓库、不依赖Spring生态、不依赖外部数据库，克隆代码就能跑，适合教学和面试讲解。

这套管理系统采用的方案不是“退步”，而是一个刻意而为的纯净环境。就像练武功先扎马步，跳过基础直接学套路，看起来学得快，但根基不稳。

2.3 功能边界与角色设计

在正式编码之前，我先定义了系统的业务范围。卖鞋的后端管理系统，核心服务对象是两类人：平台运营人员（管理员）和C端购买用户。既然是“后端管理系统”，我就把重心放在后台管理侧，C端只保留必要的下单和订单查询能力。

系统核心功能模块如下：

权限设计上，我采用最经典的两种角色：管理员拥有全部菜单权限，普通用户只能操作自己的购物车和订单。登录时通过用户对象的role字段进行路由控制，菜单展示用if-else即可，但接口层做了统一校验，避免用户绕过菜单直接调用管理功能。

这个边界划分在实际开发中很有参考意义。很多学生项目把所有功能塞到一个类里，界面、逻辑、数据混在一起，看着能跑，但一加需求就崩。用角色和模块把系统切开以后，每个部分独立演化，这也是后端管理系统设计时最值得学的经验之一。

3. 系统总体架构与核心设计决策

3.1 分层架构：界面层、业务层、数据层

这套卖鞋管理系统的代码组织结构，我采用的是经典三层架构，并且严格遵循“上层依赖下层接口，下层不反向依赖”的原则。这种分层方式在家用服务器上跑非常稳定，也方便后续替换实现。

code复制cn.shoe.admin
├── view          // 界面层：控制台菜单、输入解析
├── controller    // 控制层：接收请求、校验参数、路由分发
├── service       // 业务层：核心业务逻辑处理
├── dao           // 数据访问层：文件读写、序列化操作
├── entity        // 实体层：User、Shoe、Order等POJO
├── util          // 工具类：MD5、IdGenerator、DateUtils
└── main          // 启动入口

每层职责单一：view层只负责拼接字符串显示菜单和处理用户输入，不写任何业务规则；service层只做业务判断和流程编排，不关心数据是怎么存下来的；dao层只做数据的增删改查，不知道“下单需要扣库存”这种业务约束。

为什么这么设计？因为后端管理系统最怕的就是改动牵一发动全身。比如上线以后发现订单号生成规则要调整，如果IdGenerator被view层直接调用，那改起来就要翻遍所有界面代码；但通过service层统一封装后，只需要改service里的一处调用即可。

我还额外设计了接口层。UserService、ShoeService、OrderService都是接口，具体实现在impl包里。这样做的意义在于：后续如果要把文件存储替换成MySQL，只需要新增一套dao实现，service层的核心逻辑完全不用动。这也是面向接口编程思想在实际项目中的落地。

3.2 数据存储选型：文件序列化方案解析

系统没有选择MySQL等关系型数据库，而是用文件序列化方式做持久化。这里需要解释清楚两个选择背后的权衡。

第一，为什么用文件而不用数据库？因为题目限定的环境是“JavaSE”，用JDBC连接MySQL确实也能做，但需要额外下载驱动包、配置数据库服务，这对很多还没有接触过数据库的初学者来说，学习曲线会突然变陡。文件存储的好处是零依赖、可迁移、代码直观。

第二，为什么用Java对象序列化而不用纯文本？很多人想到文件存储会习惯性地用FileWriter写文本。但买卖系统里的商品有名称、价格、库存、品牌等多个字段，如果写文本还要自己定义分隔符和解析规则，非常容易出错。我用ObjectOutputStream把整个对象列表直接序列化成二进制文件，读取时用ObjectInputStream还原成对象集合，一存一取就完成了数据持久化。

这里有一个关键点：被序列化的实体类必须实现Serializable接口，并且声明serialVersionUID。

java复制public class Shoe implements Serializable {
    private static final long serialVersionUID = 1L;
    private Long id;
    private String name;
    private String brand;
    private BigDecimal price;
    private Integer stock;
    private Boolean onSale;
    // getter/setter省略
}

serialVersionUID是序列化版本号，如果不显式声明，JVM会根据类结构自动生成。一旦类结构发生变化，比如新增一个字段，自动生成的版本号就会变，读取旧文件时会抛出InvalidClassException。显式声明为1L后，即使类增加了字段，反序列化也能兼容，只是新增字段取默认值。这个坑我在后面第5节详细讲。

3.3 为什么不做数据库连接：从架构演进的视角看扩展性

有人会问，既然以后几乎一定会换数据库，现在不就应该直接用数据库吗？我的观点是：初学者阶段先理解数据怎么“活”起来，后续再引入数据库会有一个质的飞跃。

这个系统里，我把数据访问统一封装在dao层。比如ShoeDao接口只暴露了insert、deleteById、findAll、updateById等方法，service层调用的永远是接口方法，完全感知不到底层是文件还是数据库。实际演进路径很清晰：第一步，实现FileShoeDao；第二步，加入JDBC实现JdbcShoeDao；第三步，用Spring去管理依赖注入，逐步过渡到企业级开发。

这种渐进式演进比一开始就上全套框架更符合认知规律。很多同学一上来就Spring Boot + MyBatis，数据库设计、ORM映射、事务管理一堆概念堆在一起，出了问题根本不知道是哪个环节导致的，最后只能靠猜。

4. 核心模块详细设计与实现

4.1 用户登录与权限控制：从Session到令牌校验

登录认证是整个管理系统的安全大门，我采用了一个非常轻量但机制完整的方案。用户注册时，密码不存明文，而是经过MD5加盐处理后再存储。加盐的意思是：在用户密码后面拼上一段随机字符串，再做哈希运算，这样即使两个用户密码相同，存储的哈希值也不一样。

java复制public class Md5Util {
    public static String encryptWithSalt(String password, String salt) {
        String target = password + salt;
        return DigestUtils.md5Hex(target);
    }
}

注册时生成一个6位随机数字作为盐，和用户信息一起存到用户文件里。后续登录校验时，用库里存的盐重新计算MD5，比对结果一致则登录成功。这个方案在真实项目中已经比较弱了，因为MD5本身有碰撞风险，更安全的做法是用BCrypt或PBKDF2。但在JavaSE阶段，用MD5加盐演示“密码不能明文存储”的设计思想已经足够。

登录成功后，我会在内存中设置一个全局的“当前登录用户”上下文，并且在每次执行管理员操作前判断角色。为了让这个校验可以复用，我没有在每个方法里写重复的if判断，而是封装了一个权限校验工具：

java复制public static void checkAdmin(User currentUser) {
    if (currentUser == null || !"ADMIN".equals(currentUser.getRole())) {
        throw new PermissionDeniedException("无权访问该功能");
    }
}

Controller层调用管理员相关功能时，入口处统一调用checkAdmin。这套机制虽然简单，但对应的就是Web开发中拦截器或AOP切面的雏形。

4.2 商品管理模块：集合选型与CRUD的工程化写法

商品管理是最典型的CRUD场景，但实现时有一个值得仔细考虑的点：数据集合用什么类型。

我在ShoeDao内部维护了一个Map<Long, Shoe>用来缓存商品数据，理由是：按id查询商品是最高频的操作（购物车加购、下单扣库存、后台修改价格都要先查出目标商品），HashMap的查询时间复杂度是O(1)，而如果用ArrayList做全表扫描，数据量到几万条以后就会明显变慢。

新增商品时生成唯一ID，我封装了一个IdGenerator工具类，基于时间戳加随机数生成：

java复制public static Long nextId() {
    return System.currentTimeMillis() * 1000 + new Random().nextInt(999);
}

这个生成方式在单机环境下够用，配合AtomicLong做并发递增也可以。至于修改商品，我遵循了“先查询、再修改、最后写回”的顺序，每次更新都先根据id从Map中取出对象，修改属性后重新put回map，然后触发一次持久化。

商品上架和下架操作我设计为独立方法，而不是在更新接口里通过传参控制。这样业务语义更清晰，也方便未来做操作日志埋点。比如offShelf(Long id)方法里先校验商品是否存在，再检查当前状态是不是已上架，避免重复操作：

java复制public void offShelf(Long id) {
    Shoe shoe = shoeDao.findById(id);
    if (shoe == null) {
        throw new BusinessException("商品不存在");
    }
    if (!shoe.getOnSale()) {
        throw new BusinessException("商品已处于下架状态");
    }
    shoe.setOnSale(false);
    shoeDao.update(shoe);
}

所有业务校验都放在service层，dao层只管数据存取，这也是分层的价值。

4.3 库存扣减与超卖控制：多线程场景下的数据一致性

库存管理是卖鞋系统里最有技术含量的模块。模拟真实场景：100个人同时抢购一双只有10双库存的限量鞋，如何保证不会卖出第11双？

JavaSE阶段没有Redis分布式锁，我用了synchronized关键字加锁保证同一时间只有一个线程执行扣减操作。但在设计时，我特意保留了“乐观锁”的扩展思路：给库存表加一个版本号字段，更新时比较版本号是否一致，一致才更新并递增版本号，不一致则重试。

java复制public synchronized boolean deductStock(Long shoeId, int count) {
    Shoe shoe = shoeDao.findById(shoeId);
    if (shoe.getStock() < count) {
        return false;
    }
    shoe.setStock(shoe.getStock() - count);
    shoeDao.update(shoe);
    return true;
}

deductStock方法加synchronized后，多线程同时调用时会被JVM的监视器锁串行化，保证库存判断和扣减的原子性。在实际压测中，我开了50个线程同时抢购库存为10的商品，最终只有10个线程返回成功，其余全部返回“库存不足”，说明锁是生效的。

这里要注意的是：锁的作用范围是同一个JVM实例，如果系统部署在多台机器上，每个JVM有各自的锁，就需要引入分布式锁方案。这是我们系统后续演进的方向，但在单机JavaSE应用里，synchronized已经能解决核心问题。

4.4 购物车与订单流程：状态机让订单管理井井有条

订单模块是整个系统中业务链路最长的部分。一个完整订单经历的状态包括：待付款、已付款/待发货、已发货、已签收、已取消、退款中、已退款。如果用一堆if-else管理状态转换，代码会越来越乱。我引入了状态机模式：把状态流转规则固化为一张映射表，每个状态只允许跳转到指定状态，非法操作直接拒绝。

例如已付款订单可以取消（退款）、可以发货，但不能直接改成已签收。我用一个OrderStateMachine类维护这个规则：

java复制public class OrderStateMachine {
    private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new HashMap<>();
    static {
        TRANSITIONS.put(OrderStatus.PENDING_PAYMENT,
                EnumSet.of(OrderStatus.PAID, OrderStatus.CANCELED));
        TRANSITIONS.put(OrderStatus.PAID,
                EnumSet.of(OrderStatus.SHIPPED, OrderStatus.REFUNDING));
        // 其他状态转换规则
    }

    public static void validateTransition(OrderStatus from, OrderStatus to) {
        Set<OrderStatus> allowed = TRANSITIONS.get(from);
        if (allowed == null || !allowed.contains(to)) {
            throw new BusinessException("非法的订单状态变更: " + from + " -> " + to);
        }
    }
}

这样设计以后，任何要修改订单状态的地方都必须经过状态机的合法性校验，秩序感非常强。新增一个状态时只需要修改映射表，不需要去追查散落各处的if判断。

订单号生成用“yyyyMMddHHmmss + 三位随机数”的格式，保证在同一秒内生成多个订单也不会重复。用户在下单结算时，系统会循环购物车里的条目，逐个调用库存扣减方法，任何一个商品库存不足则整个订单失败，购物车数据不发生变化。

5. 实操复现：从零搭建可运行的JavaSE卖鞋管理系统

5.1 工程搭建与运行环境准备

开发环境非常简单：JDK 8以上、任意IDE（我用的IntelliJ IDEA）、无需配置数据库。建议用Maven工程但不需要引入任何第三方依赖，把src/main/java作为源码目录即可。

为了快速演示，我直接用控制台作为前端交互入口。Main类启动后打印功能菜单，用户输入数字选择功能，系统读取输入并调用对应service方法。当然，控制台交互的体验远不如浏览器页面，但核心价值在于业务逻辑和分层设计，所以界面简陋一点不影响学习效果。

如果你想把控制台改造成Swing界面或者JavaFX桌面应用，只需要新增一个SwingView类，复用一个Controller入口即可。甚至后续接一个基于Socket的简易HTTP服务器，把JSON格式的数据返回给前端，也能实现一个mini版Web应用。

5.2 关键代码走读：Controller层的请求分发

Controller层是view层和service层的桥梁。我设计了一个统一的AdminController，里面根据菜单编号分发到不同方法：

java复制public void dispatch(String command) {
    switch (command) {
        case "1" -> shoeService.addShoe(buildShoeFromInput());
        case "2" -> shoeService.listAllShoes();
        case "3" -> orderService.listAllOrders();
        case "4" -> userService.listAllUsers();
        default -> System.out.println("无效的菜单编号");
    }
}

每个菜单项对应一个service方法。Service层返回数据后，由view层负责打印成表格形式。这种模式对应Web开发里的Controller -> Service调用链，理解以后写SpringMVC接口会非常顺畅。

5.3 数据初始化与连通性测试

系统启动时，DataInitializer会检查数据文件是否存在，如果不存在就初始化三个测试账号：管理员账号admin/admin123、普通用户buyer1/123456、buyer2/123456，并预置一批鞋款数据（Nike Air Force 1、Adidas Stan Smith等常见款式），方便立刻进入演示流程。

测试流程建议按照以下顺序走一遍：用管理员登录，查看商品列表；新增一款鞋并设置库存；退出后用普通用户登录，搜索商品、加入购物车、提交订单；再切回管理员账号，对订单进行发货操作。全部流程走通后，重启程序，检查数据是否还保留——这一步验证文件持久化是否生效。

6. 常见问题与踩坑调试实录

6.1 序列化版本号不一致导致读取失败

这个问题我在开发过程中踩过最多次。刚开始没有显式声明serialVersionUID，后面给Shoe类加了一个category字段，结果重新启动程序读取旧数据文件时，直接抛出java.io.InvalidClassException: local class incompatible，所有商品数据看起来像“丢”了。

排查思路是：先检查异常堆栈，确认是序列化版本号冲突；再用serialver命令查看新旧版本的序列化ID；最后在类上显式声明serialVersionUID，并把旧数据文件删掉重建。

提示：一旦系统发布上线，数据文件里的数据就是宝贵资产。修改实体类时一定要谨慎对待序列化兼容问题，不能随意删除字段，新增字段要设计好默认值。

6.2 文件写入频率过高导致性能下降

最开始的版本里，每次商品修改都立刻触发一次全量序列化写入。数据量小的时候感觉不到问题，但模拟到几千条商品数据后，每次操作都要等待明显的卡顿。

后来我做了优化：引入一个“脏标记”机制。修改数据时只更新内存中的Map，并标记为dirty = true；统一在每次菜单命令处理完后，检查dirty标记，如果为true才执行一次持久化。这样把多次连续的修改合并成一次磁盘写入，性能大幅提升。

这个思路本质上就是数据库里的“批量提交”，或者缓存框架里的“延迟写回”。理解这个优化点，对以后学Redis持久化策略、MySQL刷盘机制都有帮助。

6.3 并发下库存变负数

未加上锁之前，我模拟50个线程并发抢购10件库存商品，结果出现了库存变成负数的情况。原因是两个线程同时读到库存为5，各自判断“5 >= 1”满足条件，然后先后把库存减到4，实际卖出了2件但库存只减少1件。

解决办法就是给扣减方法加synchronized锁。加锁后线程串行执行扣减逻辑，不会出现同时读到同一个旧值的情况。如果你还想体验更高级的方案，可以用AtomicInteger的compareAndSet方法模拟乐观锁：

java复制public boolean casDeductStock(AtomicInteger stock, int count) {
    while (true) {
        int current = stock.get();
        if (current < count) {
            return false;
        }
        if (stock.compareAndSet(current, current - count)) {
            return true;
        }
    }
}

这里的CAS操作，本质上就是未来学习java.util.concurrent包和分布式锁时的基础。

6.4 中文乱码问题

控制台输出中文乱码是JavaSE项目的经典问题。原因是Windows平台控制台默认编码是GBK，而IDE里文件编码是UTF-8，读入的数据经过两次解码后出现乱码。

解决方法是：第一，在读取控制台输入时，用new Scanner(System.in)并尽量统一项目编码为UTF-8；第二，文件读写时明确指定编码字符集，避免依赖系统默认编码。对于对象序列化方案，因为反射机制会自动处理字符串编码，乱码问题相对少；但如果你用文本文件存储商品信息，就一定要在FileReader/FileWriter外层包上InputStreamReader/OutputStreamWriter并指定UTF-8：

java复制BufferedReader reader = new BufferedReader(
        new InputStreamReader(new FileInputStream(file), StandardCharsets.UTF_8));

6.5 功能常见问题速查

7. 实测体验与个人总结

把整个流程跑通之后，我最直观的感受是：学完JavaSE基础语法和真正能用JavaSE做出一个完整可运行的“后端管理系统”，中间差的不是知识量，而是项目组织能力和踩坑经验。

你以为自己懂代码？当你真的从零开始实现一个“卖鞋后台”，你需要重新审视曾经背过的那些概念：什么时候用ArrayList、什么时候用HashMap？synchronized加在方法上作用范围有多大？transient关键字到底用在哪些字段上？序列化文件如果损坏了怎么做好容错处理？这些都是书本上不会写但实际一定会遇到的问题。

这个基于JavaSE的淘宝卖鞋后端管理系统最大的价值，就是给你一个安全、透明的实验场。不依赖框架，没有黑盒，每一行代码都在你眼皮底下运作。你可以在里面自由地折腾：加上多线程模拟双十一秒杀、用HTTP Server做接口暴露、把数据层换成MySQL连接池——每做一步，你都比之前更理解某个框架底层到底干了什么。

最后再分享一个小技巧：如果你想把这个项目升级成Web版，不用急着去学Spring Boot全家桶，先尝试用com.sun.net.httpserver.HttpServer写一个极简HTTP服务，把Controller层的方案替换成URL路由分发，把返回内容改成JSON字符串。等这条路走通了，再去看Spring Boot，你会发现框架只是一个更强大的工具，而你已经具备了驾驭它的底层思维和代码能力。