用户甲1. 项目概述与需求拆解
1.1 为什么选择做二手商品管理系统
我最早接到这个题目的时候，第一反应是：这年头谁还用Swing写管理系统？但真正做完之后，反而觉得这个组合挺有意思的。二手商品管理系统解决的是一个非常经典的信息管理问题——有买卖双方，有商品信息，有交易记录，还要考虑商品状态的流转。用Swing来实现，在很多高校课程设计和入门项目里仍然是很主流的选型。
先说说需求端。二手交易场景其实比新商品销售更复杂，因为它多了一个“状态管理”的维度。同一样商品，可能处于“闲置中”“已被预订”“已售出”等不同状态，而且每一笔交易背后还牵扯到卖家、买家、成交价格、成交时间这些关键要素。单纯做成一个CRUD的增删改查系统不难，但如果能把商品生命周期和交易流程串联起来，这个项目的含金量就完全不一样了。
从功能模块上看，一个完整可用的二手商品管理系统至少要覆盖这几块：
- 用户管理：注册、登录、个人信息维护
- 商品管理：发布商品、修改商品信息、下架商品
- 分类管理：商品分类的增删改查，方便用户筛选
- 交易管理：下单购买、订单状态跟踪、交易记录
- 搜索与筛选：按关键词、价格区间、分类等条件查找商品
1.2 目标用户与核心使用场景
这个系统的目标用户很明确，就是校园里的大学生或者社区里的居民。这类用户群体有一个共性：手上有闲置物品想出手，但又不愿意走大平台的繁琐流程。所以系统的操作路径应该尽量短，比如发布商品从点击按钮到信息填完，应该控制在两三分钟内完成。
使用场景可以这样理解：小王有一台用了两年的iPad，想卖给学弟。他打开系统，注册账号，点击“发布商品”，上传几张实拍图，填好型号、成色、期望价格，提交之后就等着买家来联系。另一边，想买iPad的小李通过分类浏览或关键词搜索找到了这台iPad，看到成色描述和价格都合适，直接下单购买。卖家收到订单提醒后，线下完成交付，在系统里把订单状态改为“已完成”。一整个流程下来，系统就像一个线上的跳蚤市场管理员，把商品信息和交易记录都管得清清楚楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Swing技术选型解析
2.1 为什么在这个项目中选Swing
我见过不少人在技术选型上纠结很久，其实对于这类桌面端管理系统，Swing依然是性价比很高的选择。没有前端三件套的割裂感，没有Maven依赖地狱，一个JDK装好就能开干，这对教学和课程设计来说非常友好。
Swing是Java自带的GUI工具包，从JDK 1.2开始就内置了，最大的优势就是跨平台。同一个jar包，在Windows、macOS、Linux上跑起来界面表现基本一致，不需要额外打包适配。对于Windows开发、Windows演示、可能还要在别的机器上答辩的场景，Swing的跨平台特性减少了很多环境冲突。
另一个让我坚持选Swing的原因是：它和Java的配合实在太天然了。业务逻辑用Java写，界面也用Java写，全程不用切换语言上下文。项目里需要操作数据库的话，直接JDBC或者MyBatis接上就行，不需要像Web项目那样搞一堆Controller、Service、Mapper的分层映射，代码量能省下不少。
2.2 Swing与JavaFX、Web方案的对比
很多人会问：既然都是Java生态，为什么不选JavaFX？或者干脆做Web系统？这里我做一个直观的对比：
| 对比维度 | Swing | JavaFX | Web（SSM/Spring Boot） |
|---|---|---|---|
| 学习曲线 | 平缓，组件API简单 | 稍陡，FXML和属性绑定要额外学 | 陡峭，前后端都要掌握 |
| 运行环境 | JDK内置，无需额外依赖 | JDK 8后需要单独引入模块 | 需要部署Tomcat或内嵌容器 |
| 界面表现力 | 一般，偏传统 | 较强，支持CSS美化 | 取决于前端技术栈 |
| 团队协作 | 单人即可完成 | 适合单人 | 需要前后端分工 |
| 部署复杂度 | 打jar包直接运行 | 打jar包需注意模块依赖 | 需要服务器环境 |
| 适合场景 | 课程设计、小型管理系统 | 中型桌面应用 | 互联网级应用 |
从这个表格能看出来，Swing的定位非常清晰：它不是为了做炫酷的界面而生的，但做内部管理系统这种偏“工具属性”的软件，完全够用。尤其是课程设计和中小型项目答辩，评委关注的核心其实是业务逻辑是否完整、数据库设计是否合理、代码结构是否清晰，这些方面Swing完全能扛住。
2.3 技术栈配套方案
选定了Swing之后，配套的技术栈也要仔细考虑。我的建议是这样一套组合：
- JDK版本：JDK 8或JDK 11。别追新用JDK 17以上的版本，因为部分老教程里的Swing代码在新版本上会有一点点细节差异，而且JDK 8在课程设计中认可度最高，环境问题最少。
- 界面布局：纯代码布局，不用IDE的可视化拖拽。可视化布局生成的代码又长又乱，后期改一个组件的尺寸可能牵扯到几十行代码的变动，完全是给自己挖坑。
- 数据库：MySQL 5.7或8.0，通过JDBC连接，也可以封装一层DBUtil工具类，简化连接管理。
- 连接池：如果项目体量不大，直接用DriverManager获取连接就够了。想体现专业性，可以引入Druid或C3P0，但核心逻辑是一样的——获取连接、执行SQL、关闭资源。
这套组合最大的好处就是“清爽”：依赖少、环境简单、代码可控，即使整个项目重构，核心逻辑也不会受到框架绑架。
3. 系统架构与数据库设计
3.1 分层架构设计思路
很多初学者写Swing项目，最喜欢把所有代码一股脑塞进事件监听器里。点击一个按钮，下面跟着二三十行代码：获取文本框内容、拼SQL、查数据库、解析结果、刷新表格。这种写法的痛点非常明显：改一个功能的时候要像考古一样在几百行代码里翻找逻辑，排查问题的成本极高。
我在这套系统里采用了经典的三层架构：
- 视图层（View）：只负责界面的展示和事件的触发，包括JFrame、JPanel、JTable这些组件的布局，以及对用户操作的响应入口。
- 控制层（Controller）：接收视图层传来的操作指令，调用业务逻辑层的方法，并把结果封装好返回给视图层。在Swing里，控制层通常由事件监听器承担，但我建议把监听器里的逻辑单独抽到Controller类里，而不是全部写在匿名内部类中。
- 业务逻辑层（Service）与数据访问层（DAO）：Service负责业务规则的校验和流程控制，DAO负责与数据库交互。这两层可以分开，也可以合并，具体看代码规模。但我强烈建议至少保留一个大致的边界，哪怕不单独建类，也要在注释或者方法命名上区分开。
分层之后，核心收益是：界面和逻辑解耦，以后想从Swing换成JavaFX，或者从桌面端扩展出Web端，底层的Service和DAO可以原样复用。
3.2 数据库表结构设计
数据库设计决定了系统能跑多远。我的建议是至少设计五张表：用户表、商品分类表、商品表、订单表、订单明细表。下面给出每张表的核心字段设计思路。
用户表（t_user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| user_id | INT 主键自增 | 用户ID |
| username | VARCHAR(50) 唯一 | 登录用户名 |
| password | VARCHAR(100) | 登录密码，建议MD5加密 |
| nickname | VARCHAR(50) | 昵称 |
| phone | VARCHAR(20) | 联系电话 |
| create_time | DATETIME | 注册时间 |
密码加密这点特别重要。很多Swing课程设计项目都是明文存密码，这在实际系统中是绝对不能接受的。MD5加密虽然已经被认为不够安全，但作为课程设计和学习项目已经比明文强出几个量级，而且实现成本极低。
商品分类表（t_category）
|