简介：一款基于Java Swing开发的象棋人机对弈完整项目，核心采用极大极小值搜索算法实现电脑落子决策，适合计算机专业毕业设计、课程设计或期末大作业参考。项目包含界面交互、棋子规则判定、局面评估与搜索剪枝等模块，代码结构清晰，Java类文件按功能划分便于阅读改造，同时配有PNG/JPG棋子和棋盘素材、WAV音效资源、项目说明文档及配置信息。包内共150个文件，以74个Java源码为主，辅以图片、音频、Markdown说明和XML配置，压缩包约3.03MB，内容精炼紧凑，便于本地快速部署验证。该资源已在CSDN有242人浏览学习，属于导师指导下高分通过的设计项目，适用人群覆盖从零基础学生到需要项目实战练习的开发者。除完整源码外，还附有文档说明，可帮助理解整体架构与算法流程；若基础薄弱，也可与作者交流获取运行指导，或在此基础上进行二次开发、定制功能。
1. 基于Java Swing的象棋游戏源码：人机对弈的核心在搜索算法，不在界面
如果你搜过 Java 课程设计或桌面小游戏案例，大概率见过这种标题：基于 Java Swing 的象棋游戏，极大极小值搜索算法实现人机对弈，附带文档说明。这类项目在国内技术社区里流传很广，价值不在于界面有多炫，而在于它是一个完整的、能跑通的闭环——Swing 负责画棋盘和接收鼠标，极大极小值搜索算法负责让电脑"思考"走哪步。对想补 Swing 实战、又想理解搜索算法怎么落地的人来说，这是性价比很高的一份源码。
它的核心逻辑并不复杂：把棋盘建模成二维数组，走法生成器枚举所有合法落子，评估函数给局面打分，然后让极大极小值搜索在"我走一步、你走一步"的递归里找到对自己最有利的分支。真正让新手卡住的地方往往是三个：走法生成漏了规则边界、评估函数权重设得离谱、搜索在事件分发线程里跑导致界面假死。这篇文章会按"骨架拆解 → 搜索算法落地 → 完整调用链 → 踩坑记录 → 进阶优化"的顺序，把这个项目从头到尾讲透，让你拿到源码后能跑通、能读懂、能改强。
2. 拆解项目骨架：Swing界面、棋盘模型与规则引擎怎么各司其职
2.1 解压到开工：先看懂目录结构再动手
拿到 zip 包，第一步不是急着点运行，而是先看清目录。这类 Swing 象棋项目一般不会用 Maven 或 Gradle 管理依赖，而是纯 Java 工程，直接以 src 目录作为源码根。我习惯先执行一条命令把结构摸清楚：
unzip 基于java_swing的象棋游戏源码.zip -d chess-project cd chess-project find . -type f -name "*.java" | sort正常你会看到类似这样的分包方式：ui 包放主窗口、棋盘面板和棋子绘制；model 或 core 包放棋盘类、棋子枚举和走法生成；ai 或 search 包放评估函数和极大极小值搜索；util 包放一些公共工具。这种分包本身就是很好的学习材料——它告诉你一个桌面游戏项目该有的模块边界在哪。我一般会先打开入口类，通常是某个带 main 方法的 JFrame 子类，确认窗口标题、棋盘大小和默认难度这些可调参数放在哪里，再往下读。
启动入口本身没有太多玄学，无非是在 main 方法里创建 JFrame、初始化棋盘 Panel、设置布局和可见性。值得留意的是棋盘 Panel 的绘制方式——多数实现会重写 paintComponent，用 Graphics2D 画 9 条竖线、10 条横线，以及河界和九宫斜线，然后按行列坐标把棋子画成圆形加中文文字。如果你后续想改棋盘颜色、棋子样式或加动画，都是在 paintComponent 里动手，不在别处。
2.2 棋盘与棋子的建模方式：把规则变成Java对象
象棋棋盘是 9 列 10 行，绝大多数实现会用一个二维数组来存局面。元素为 0 表示空位，正整数表示红方棋子，负整数表示黑方棋子。这种 int 数组方案比用对象集合更省内存，而且走子和悔棋时只需改两个下标，拷贝局面做搜索也很方便。我看到的大部分源码会定义一个 ChessBoard 类封装这个数组，并提供 makeMove、unmakeMove、isLegalMove 这几个核心方法。下面是一个典型的建模片段：
// ChessBoard.java 核心结构示意 public class ChessBoard { public static final int EMPTY = 0; // 红方棋子用正数，黑方用负数，MARK 用于标记棋子类型 public static final int RED_KING = 1000, RED_ROOK = 500, RED_KNIGHT = 400; public static final int RED_CANNON = 450, RED_BISHOP = 200, RED_GUARD = 200, RED_PAWN = 100; // 黑方直接取相反数，便于用 Math.abs 判断棋子类型 private int[][] board = new int[10][9]; public int getPiece(int row, int col) { return board[row][col]; } public void makeMove(Move move) { board[move.toRow][move.toCol] = board[move.fromRow][move.fromCol]; board[move.fromRow][move.fromCol] = EMPTY; } public void unmakeMove(Move move) { board[move.fromRow][move.fromCol] = board[move.toRow][move.toCol]; board[move.toRow][move.toCol] = move.capturedPiece; } }用 int 而不是对象，还有一个实际好处：评估函数要高频读取棋盘，数组访问比对象字段访问快得多；搜索算法要反复 makeMove 和 unmakeMove，用 int 做快照或者回退都更轻。Move 类一般是简单的 DTO，包含 fromRow、fromCol、toRow、toCol、capturedPiece 五个字段。象棋的吃子规则决定了 capturedPiece 在 unmakeMove 时必须被正确恢复，否则搜索完一个分支后局面就乱了，这是很多人调试 AI 时最头疼的问题之一。
2.3 走法生成的边界：别让马脚、象眼和将帅照面毁掉整局
走法生成器是整个搜索算法的地基。它负责在给定局面下返回所有合法走法，而这一步最容易漏规则。象棋里最容易写错的是四个点：马被蹩马腿、象被塞象眼、士和将不能离开九宫、将帅不能直接照面。很多粗糙的源码把马写成"日字移动"就完事，忽略蹩腿判断，结果 AI 能走出明显违规的棋，用户一眼就觉得垃圾。
这里给一个马走法的生成逻辑做参考：
// 马的走法：先判断马腿，再判断目标位置 private static final int[][] HORSE_MOVES = { { -2, -1 }, { -2, 1 }, { -1, -2 }, { -1, 2 }, { 1, -2 }, { 1, 2 }, { 2, -1 }, { 2, 1 } }; // 马腿方向：与每个偏移对应的“紧邻”位置 private static final int[][] HORSE_LEG = { { -1, 0 }, { -1, 0 }, { 0, -1 }, { 0, 1 }, { 0, -1 }, { 0, 1 }, { 1, 0 }, { 1, 0 } }; public static void generateHorseMoves(ChessBoard board, int row, int col, List<Move> moves) { for (int i = 0; i < HORSE_MOVES.length; i++) { int legRow = row + HORSE_LEG[i][0]; int legCol = col + HORSE_LEG[i][1]; // 马腿位置有棋子则不能跳 if (board.getPiece(legRow, legCol) != ChessBoard.EMPTY) { continue; } int toRow = row + HORSE_MOVES[i][0]; int toCol = col + HORSE_MOVES[i][1]; if (isInBoard(toRow, toCol) && !isSameSide(board.getPiece(row, col), board.getPiece(toRow, toCol))) { moves.add(new Move(row, col, toRow, toCol, board.getPiece(toRow, toCol))); } } }这段代码的关键在两个数组的对应关系：HORSE_MOVES 里每一项的"日字偏移"，在 HORSE_LEG 里存的是它紧邻起点的那一格。比如马从 (3,3) 跳到 (1,2)，偏移是 (-2,-1)，马腿是 (2,3)，也就是说 (2,3) 有子则不能走。这个对应关系每一组都要人工核对，漏一组就是"某些方向被错误封死，另一些方向又能穿腿"。我的习惯是写完走法生成器后，单独跑一个"把某子放在典型位置、枚举全部走法"的小测试，把结果和真实象棋规则比对一遍，再去接搜索算法。否则搜索层数越多，规则 bug 被放得越大。
3. 极大极小值搜索落地：评估函数、搜索深度与Alpha-Beta剪枝的配合
3.1 评估函数是AI的"棋感"：子力价值、位置调整与威胁判断
极大极小值搜索本身没有智能，它只是在博弈树里找一条最优路径。棋下得好不好，完全取决于评估函数这个黑匣子怎么打分。常见做法是给每个棋子定基础价值，再叠加上位置分。子力价值表可以参考这个量级：将帅无穷大，车约 1000，马约 400，炮约 450，仕相各 200，兵卒 100。注意炮和马的相对关系在不同局面下会变化——残局里马比炮好用，开局相反，很多源码不做这种动态调整，AI 照样能赢新手，问题不大。
位置分是拉开 AI 水平差距的地方。兵过河后每前进一步加分，马在中心位置比在边角更有价值，车占住肋道要加分，这些都可以用一张 10 行 9 列的位置价值表来实现。红方和黑方要对称，所以黑方取分时会把行号翻转。评估函数最后返回的是红方视角的总分，正分表示红方占优，负分表示黑方占优。AI 自己是红方时就选正分大的走法，是黑方时就选负分小的走法。一个常见的评估函数大概长这样：
// 简化版评估函数：红方正分，黑方负分 public int evaluate(ChessBoard board) { int score = 0; for (int row = 0; row < 10; row++) { for (int col = 0; col < 9; col++) { int piece = board.getPiece(row, col); if (piece == ChessBoard.EMPTY) continue; int absVal = Math.abs(piece); int baseVal = PIECE_VALUE[absVal]; // 按行列索引查位置表，黑方上下翻转 if (piece > 0) { score += baseVal + RED_POSITION_VALUE[absVal][row][col]; } else { score -= baseVal + BLACK_POSITION_VALUE[absVal][row][col]; } } } return score; }位置表不是越大越好，它会让评估函数偏向某些局部形态，反而丢了棋局的整体判断。我见过某版源码把位置表权重调得太高，AI 为了占中心不惜送车，这就是典型的评估函数翻车——基础子力价值必须占主导，位置分只是微调。一般来说，位置分控制在子力价值的 10% 到 20% 之间比较稳妥。评估函数调好后，AI 的水平上限就基本定了，搜索深度只是让它的稳定性更好。
3.2 极大极小值递归框架：让AI看到"我走一步，你会走一步"
极大极小值的思路很简单：假设自己是红方，轮到红方走这一步时，要从所有合法走法里选一个最高分；但走完之后轮到黑方，黑方会选自己的最高分，也就是红方的最低分。这个"选最大、再选最小、再选最大……"的交替过程，就是递归的本质上。每一层轮流切换 max 和 min 视角，搜索到指定深度后，用评估函数给叶子节点打分，然后逐层回传。
实现上有两种流派：一种是正统的 minimax，max 层和 min 层分开处理；另一种是 negamax，利用"对手的最大分就是己方的负最小分"这个对称性，把两层逻辑合并成一段。象棋源码里两种都有，我个人更喜欢 negamax，代码短，而且层间切换只需要一个负号。下面是一个不剪枝的极大极小值框架，先看懂它再往上加剪枝：
// 极大极小值搜索：depth 为剩余搜索层数，isMax 为当前层是否选最大分 public int minimax(ChessBoard board, int depth, boolean isMax) { if (depth == 0 || board.isGameOver()) { return evaluate(board); } List<Move> moves = generateAllMoves(board); if (moves.isEmpty()) { return evaluate(board); // 无棋可走，按当前局面打分 } if (isMax) { int best = Integer.MIN_VALUE; for (Move move : moves) { board.makeMove(move); best = Math.max(best, minimax(board, depth - 1, false)); board.unmakeMove(move); } return best; } else { int best = Integer.MAX_VALUE; for (Move move : moves) { board.makeMove(move); best = Math.min(best, minimax(board, depth - 1, true)); board.unmakeMove(move); } return best; } }这段代码的逻辑链是这样：isMax 为 true 的层是 AI 的回合，它遍历所有走法，每走一步就递归进入对手回合，取递归结果的 Math.max；isMax 为 false 的层是对手回合，取 Math.min。unmakeMove 必须放在递归返回之后执行，这保证同一层多个走法之间棋盘状态是干净的。这里有个容易犯的错——把 makeMove 写在 try 块里或者忘记恢复 capturedPiece，第二层递归回来时棋盘已经脏了，分数全部失真。
不剪枝的 minimax 在实际项目里几乎不可用。象棋平均走法数量在 40 左右，深度 4 层就要算 40^4 即 256 万个叶子节点，纯 Java 单线程跑起来会让人等到怀疑人生。所以绝大多数源码的搜索函数都会带上剪枝优化，也就是下面这一节的主角。
3.3 Alpha-Beta剪枝：深度和性能的取舍，剪枝顺序决定提速效果
Alpha-Beta 剪枝是在极大极小值框架上增加两个边界参数：alpha 是已搜索分支里对当前层最好的分数下限，beta 是上限。当某一层的某个分支分数已经让对手无法接受时，后面的分支就不必再搜。这段逻辑理解起来有点绕，但写成代码并不复杂，通常是给 minimax 加上 alpha 和 beta 参数：
// Alpha-Beta 剪枝版极大极小值搜索 public int alphaBeta(ChessBoard board, int depth, int alpha, int beta, boolean isMax) { if (depth == 0 || board.isGameOver()) { return evaluate(board); } List<Move> moves = generateAllMoves(board); if (isMax) { int best = Integer.MIN_VALUE; for (Move move : moves) { board.makeMove(move); int score = alphaBeta(board, depth - 1, alpha, beta, false); board.unmakeMove(move); best = Math.max(best, score); alpha = Math.max(alpha, best); if (beta <= alpha) { break; // beta 剪枝：对手不会让局面走到这一层 } } return best; } else { int best = Integer.MAX_VALUE; for (Move move : moves) { board.makeMove(move); int score = alphaBeta(board, depth - 1, alpha, beta, true); board.unmakeMove(move); best = Math.min(best, score); beta = Math.min(beta, best); if (beta <= alpha) { break; // alpha 剪枝 } } return best; } }剪枝代码本身只多了三行：更新 alpha 或 beta，然后判断是否提前 break。大道至简，真正的性能差异来自剪枝发生的时机。如果每次搜索第一个走法就是最优解，剪枝效率最高，大约能覆盖 90% 以上的分支；如果第一个走法很差，剪枝几乎不生效，搜索退化成完整 minimax。这就是为什么走法排序如此重要——把吃子和将军的走法排在最前面，Alpha-Beta 才能发挥威力。深度参数方面，我的建议是从 3 层开始调试，带剪枝的情况下 4 层可以在普通笔记本上做到秒级响应，5 层就需要走法排序做得好才能勉强接受。
4. 人机对弈的最小闭环：从点击棋子到AI落子的完整调用链
4.1 玩家走子的合法性校验与回合流转
界面和算法之间需要一个桥。这个桥通常由一个 Controller 或 Game 类来承担，它持有棋盘对象、当前回合标记和选中棋子坐标。玩家点击棋盘面板后，MouseListener 拿到的是像素坐标，要把它转换成 0-9 的列和 0-10 的行，再交给规则层判断。转换公式不用记，就是面板宽度除以 9、高度除以 10，用像素值取整。但要注意棋盘的边距和网格偏移，不处理的话点击位置会整体偏移一格，这是 Swing 棋盘项目里很常见的手感问题。
回合流转的状态机是这类项目的核心骨架。可以用一个枚举 State 表示"等待选子"、"已选中棋子"、"轮到AI"，每次点击都根据当前状态决定下一步行为。伪代码大概是：等待选子状态下，如果点到了己方棋子，就进入已选中状态并高亮；已选中状态下，如果点到合法目标格，执行走子、切换回合；如果点到其他己方棋子，则更换选中对象。这个状态机写清楚后，玩家侧的逻辑就不会乱，AI 侧只需要在轮到它时触发一次搜索方法。
// 棋盘面板的鼠标事件简版处理 public void mouseClicked(MouseEvent e) { int col = e.getX() / cellWidth; int row = e.getY() / cellHeight; if (state == State.WAITING_SELECT) { if (isOwnPiece(row, col)) { selectedRow = row; selectedCol = col; state = State.PIECE_SELECTED; repaint(); } } else if (state == State.PIECE_SELECTED) { Move move = new Move(selectedRow, selectedCol, row, col, board.getPiece(row, col)); if (board.isLegalMove(move)) { board.makeMove(move); state = State.AI_TURN; aiMove(); } } }这段代码里最容易出问题的点是 isLegalMove 和 makeMove 之间的状态一致性。真实项目里 isLegalMove 往往只做规则校验，不修改棋盘，makeMove 才真正落子。一旦顺序写错，比如先 makeMove 再校验，或者校验时临时修改了棋盘没有恢复，就会出现"界面显示走了、AI 眼里棋盘没变"的诡异局面，而且很难排查。我建议在 makeMove 前后各打一条日志，把 from、to、capturedPiece 都打出来，调试期能省一半时间。
4.2 AI走子的触发时机与搜索线程的选择
AI 触发方式是这个项目里最容易被新手搞砸的地方。如果直接在鼠标事件里调用搜索方法，界面会在搜索期间完全卡死——因为鼠标事件在事件分发线程（EDT）上执行，而搜索是 CPU 密集型任务。小深度（3 层）可能只是卡几百毫秒，深度调到 5，卡顿时间足够让用户以为程序崩了。正确做法是把搜索丢到单独的线程里，搜索完再回到 EDT 更新棋盘。
我一般用 SwingWorker<T, V> 来做这件事。它专为这类场景设计： doInBackground 里跑耗时任务， done 方法在 EDT 上执行 UI 更新。下面是搜索任务的封装示意：
// 搜索任务：在后台线程跑 Alpha-Beta，完成后回到 EDT 落子 private void aiMove() { ChessBoard snapshot = board.clone(); // 搜索会反复 make/unmake，绝不能直接用 UI 棋盘 SwingWorker<Move, Void> worker = new SwingWorker<>() { @Override protected Move doInBackground() { return ai.searchBestMove(snapshot, depth); } @Override protected void done() { try { Move best = get(); board.makeMove(best); state = State.WAITING_SELECT; repaint(); } catch (InterruptedException | ExecutionException ex) { // 记录异常，恢复成等待玩家选子状态 } } }; worker.execute(); }这段代码有两个细节值得注意。第一个是 snapshot = board.clone()——搜索函数内部会大量 makeMove 和 unmakeMove，如果直接传 UI 的棋盘对象，搜索结束后棋盘状态可能因异常而残留改动，导致 UI 和逻辑层对不上。clone 这块开销在象棋这个量级上完全可以接受。第二个是 done 方法里的状态恢复：如果 AI 搜索抛异常，一定要把 state 复位成 WAIT_SELECT，否则玩家会陷入"轮到我走但点了没反应"的死锁。很多源码没做异常处理，一旦 AI 走出非法走法，整个对局就废了。
4.3 文档说明怎么读：接手这个项目最快的路径
标题附带的"文档说明"在zip包里通常占了不小比例。不要把它当成摆设，它是你快速定位代码的关键。这类文档一般会写清楚：运行环境要求、项目包结构、核心类职责、搜索算法的流程和参数位置。我的习惯是拿到文档先只看三样东西：运行命令或入口类名、搜索类里有哪些可调参数、走法生成器放在哪个类。这三样能让你在十分钟内确定项目能不能跑、AI 能不能调、改起来要动哪儿。
读文档时要特别注意它和源码是否匹配。我遇到过文档描述了一个两年前的重构版本，类名和现实代码完全对不上，照文档找类必然翻车。这种情况不要慌，用 IDE 的全局搜索按类名或方法名找，比通读文档效率高得多。文档里最值得精读的往往是搜索算法的伪代码或流程图，因为它能帮你理解作者当时的思路——是先做评估还是先做剪枝、深度默认为什么是这么多。这份理解是你后续调优的基础，也是你在答辩或面试时能讲出"为什么这么设计"的底气。
5. 避坑记录：跑这个项目最容易翻车的5个地方
5.1 中文乱码：源码注释全变问号，棋子名字显示成方块
现象：用 IDEA 或 Eclipse 打开源码，注释全是乱码；运行后棋盘上的"车马炮"变成一串问号或方块。原因基本只有一个：源码文件是 GBK 编码，而 IDE 默认用 UTF-8 读取。Swing 程序的文本渲染和源文件编码是两回事，但很多人第一眼看到乱码就以为棋盘绘制代码有 bug。
解决：在 IDE 里把项目文件编码切换成 GBK 再重新打开；如果项目里混用了编码，就统一转成 UTF-8。我一般用命令行批量转码：
find src -name "*.java" -exec iconv -f GBK -t UTF-8 {} -o {}.tmp \; -exec mv {}.tmp {} \;转码后记得检查一遍文件名有没有后缀残留，这个命令写不好会把 .java 文件变成 .java.tmp。转完之后在 IDE 里重新加载，乱码基本清干净。棋子绘制文字乱码还可能是字体问题，但概率很低，优先怀疑编码。
5.2 AI 长考卡死：深度调高后搜索时间暴涨，或陷入死循环
现象：把搜索深度从 3 改成 5，点击界面后 AI"思考"十几秒都不落子，甚至直接卡死。原因有两个方向：一是没有走法排序，Alpha-Beta 剪枝失效，搜索量退化成接近全量枚举；二是走法生成器里有一个 bug 导致同一局面反复生成相同走法，递归无法收敛。
解决：先用日志确认是否真的进入了搜索、以及每次递归的剩余深度是否严格递减。在 alphaBeta 方法入口打一行 depth 日志，看有没有深度不减甚至增加的记录。深度没问题的话，就是剪枝效率问题——别急着优化走法排序，先加一个搜索超时的兜底逻辑，比如只允许搜索 3 秒，到时返回当前最好结果。这个兜底虽然会损失一点棋力，但至少保证程序不假死。稳定后再回头做走法排序。
5.3 将帅照面被判定合法：AI 走出明显送将的棋
现象：AI 走完后，棋盘上两个光杆将帅直接面对面，按规则这是非法局面，但程序毫无反应。原因是走法生成器只判断了单子移动的合法性，漏掉了"将帅不能照面"这条全局约束。这两个棋子之间没有棋子时，将帅不能互相进入对方的直线攻击范围，这在吃子规则里尤其容易被忽略。
解决：在走法生成完成之后加一个局面合法性校验，判断移动后双方将帅是否直接照面，如果照面则删除该走法。更规范的做法是在 makeMove 之后调用一个 isKingSafe(board) 函数，把整个局面丢进去检查。注意这段校验必须在搜索内部同样生效，不能在 UI 层校验一次就完事——搜索走出的分支如果包含送将走法，评估函数会给它很高分，AI 反而会主动送将。
// 检查将帅是否照面：同列且中间无棋子则非法 private boolean kingsFacingEachOther(ChessBoard board) { int redKingCol = findKingCol(board, true); int blackKingCol = findKingCol(board, false); if (redKingCol != blackKingCol) return false; int redKingRow = findKingRow(board, true); int blackKingRow = findKingRow(board, false); int minRow = Math.min(redKingRow, blackKingRow); int maxRow = Math.max(redKingRow, blackKingRow); for (int row = minRow + 1; row < maxRow; row++) { if (board.getPiece(row, redKingCol) != ChessBoard.EMPTY) { return false; } } return true; }5.4 悔棋与复盘状态错乱：棋盘回退到一半就"变牌"
现象：连续悔棋两三次后，棋盘上的棋子数量和位置对不上，甚至出现两个车在同一格。原因几乎总是后悔棋的数据结构选错了。如果源码用 List 保存每步快照，那么快照必须在 makeMove 之前 clone；如果 clone 是浅拷贝，int[][] 数组被多处引用，悔棋时改的就是同一个数组。
解决：要么给 ChessBoard 实现深拷贝的 clone 方法，要么用 undo 栈记录 Move 对象，悔棋时反向执行 unmakeMove。我推荐后一种方案，内存占用小、逻辑直观，而且正好复用搜索里已经在用的 unmakeMove。要注意 unmakeMove 必须恢复 capturedPiece，如果 Move 对象里没存这个字段，悔棋回来棋子就消失了。你可以检查一下源码的 unmakeMove 是不是只恢复移动，不恢复被吃的子——这是最典型的半吊子实现。
5.5 界面假死：鼠标点击无响应，窗口变成"未响应"白屏
现象：AI 思考期间，整个窗口无法拖动、无法最小化，标题栏出现"未响应"。原因很直接：搜索代码跑在了事件分发线程（EDT）上。很多源码偷懒，直接在 mouseClicked 里调用 aiMove()，而 aiMove 内部是同步的 alphaBeta 搜索。深度 3 层可能只卡一两秒，用户能忍；深度 5 层卡十秒，用户直接关窗口。
解决：把搜索丢到 SwingWorker 或普通 Thread 里，并在搜索期间禁用棋盘交互（比如把面板的 clickable 置为 false），避免用户重复点击触发多个搜索任务。搜索完成后回到 EDT 更新棋盘，重新启用交互。这里还要注意一个并发细节：后台线程在读棋盘时，UI 线程不能在另一个线程里 makeMove，否则两个线程同时改 int[][] 数组，数据会串。SwingWorker 的 done 方法天然回到 EDT，所以"搜索在后台、落子在 EDT"这个时序是安全的。
6. 把这个棋局AI调得更强：走法排序、置换表与开局库的三种进阶
人机对弈做到"能下"只是起点，"下得好"才是这个项目真正拉开差距的地方。我接手过几个类似的 Swing 象棋源码，评估这个项目值不值得投入，就看它留没留这三个扩展口：走法排序、置换表和开局库。三者按性价比排序，走法排序最值得先做，它改动最小、收益最直接。给走法排个序，让吃子、将军这些大概率优秀的走法排在前面，Alpha-Beta 剪枝效率能提升好几倍，同样的深度下 AI 明显变强。
置换表是第二步。极大极小值搜索在反复 makeMove 和 unmakeMove 的过程中，同一个局面会以不同走法顺序被访问多次。用 HashMap 把已评估的局面对应的分数存起来，每次进入节点先查表，命中就直接返回，能免掉大量重复计算。注意键值要用局面特征值或深拷贝的棋盘对象，否则会产生串键导致分数错乱。这个优化对棋力提升不如走法排序明显，但它是省时间的重要手段，做完之后你就能把搜索深度从 4 提升到 5 而不担心卡顿。
开局库是第三个层次，也是最接近真实棋软的做法。深搜索在前几步是无头苍蝇——开局阶段棋子多、选择多，评估函数很容易做出不符合棋理的选择。常见做法是把著名开局的前 4 到 6 手存成一张表，轮到 AI 走这一步时直接从表里随机挑一个走法。这样做有三个好处：避开深搜索在前几步的低效和盲区，让 AI 开局看起来有套路，同时减少前几步的搜索耗时。缺点是如果源码没有设计开局库的接口，你需要自己加一个前置判断——搜索深度大于一定值或者剩余棋子数量达到阈值时，走法从开局库优先选择，否则走搜索。
// 开局库的接入示意：前6步走固定套路，之后才进入搜索 public Move decideMove(ChessBoard board, int moveCount) { if (moveCount <= 6) { Move opening = openingBook.lookup(board); if (opening != null) { return opening; } } return alphaBetaSearch(board, DEFAULT_DEPTH); }我一般还会顺手做一件事：加参数面板，让深度和搜索时间可以在界面里调整，而不是改代码重编译。这样调试评估函数时，把深度设成 2 就能快速验证每个走法的分数变化；想测棋力再把深度拉回 5。这种可配置能力比把数值硬编码在常量里好用得多，也是衡量这个源码设计是否灵活的最小标准。如果你打算拿这个项目做课程设计或者进作品集，这三个优化做下来，完全够你写出一份有分量的说明文档——至少比单纯复述源码里的原理要实在得多。
这套东西我做过不止一遍，每次最容易栽的还是在细节上——编码、线程、照面规则，跟界面多漂亮、算法多高深完全无关。先把这些底子打牢，再谈优化，才是把这份源码吃到嘴里的正路。希望这些经验能帮你少走几步弯路。
本文还有配套的精品资源，点击获取
