简介：用C语言实现的中国象棋游戏完整工程源码，适合C语言初学者、数据结构和算法课程设计者，以及想借助经典棋类项目锻炼逻辑与编程能力的开发者。资源覆盖棋盘棋子数据结构、走法合法性检查、吃子与胜负判定、命令行交互等核心模块，并体现简单AI对弈思路，可作为课程设计或毕业设计的直接参考。
压缩包共85个文件，仅143KB，包含14个.h头文件、10个.cpp源文件、38个ico图标和6个cur光标，以及工程配置、说明文档和可直接运行的exe。头文件与源文件分工明确，覆盖界面绘制、棋局逻辑、AI思考等模块；ico/cur用于界面元素；readme和GPL文本便于阅读与再分发。目前已有994人学习浏览，适合快速下载对照实践。
代码结构清晰，MantisChessThink等模块展示走法生成与评估思路，便于剖析象棋规则的程序化表达；整个工程麻雀虽小五脏俱全，是学习C语言工程组织与棋类算法实现的优质示例。 做中国象棋这个项目，是我在带C语言学习时最常推荐的一个练手题目。原因很简单：它不依赖任何第三方库，纯用C语言的控制台就能跑起来，但麻雀虽小五脏俱全——棋盘、棋子、规则、走法生成、人机对弈、输入输出，全都有了。很多朋友问我要“中国象棋 c语言源代码”，其实真正缺的不是代码本身，而是“源代码是怎么一步步设计出来的”这条思考路径。这篇博文就把整个项目的核心设计、关键实现和我在写代码过程中踩过的坑，一次讲明白。
文章适合正在学C语言、想做点像样项目的朋友，也适合拿它当课程设计或期末大作业的同学。不需要你有图形界面基础，也不需要懂高深算法，只要掌握数组、函数、结构体和递归的基本用法，就能跟着这篇文章把项目搭起来。我会从整体架构讲到具体代码，再讲调试经验和AI搜索，最后给出完整的工程组织建议。
1. 项目概述与目标拆解
1.1 这个项目到底在解决什么问题
初次接手这个项目的人，最大的困惑往往是：不知道从哪里开始。这其实是因为“中国象棋”四个字背后藏着太多子问题：棋盘怎么存？棋子怎么表示？每种棋子的走法怎么编码？“马走日，象走田，炮打隔子”这些规则怎么翻译成if语句？红黑双方轮流走棋的主循环怎么写？电脑怎么自动应对玩家的走棋？
把这些子问题拆开看，每一块都不算难，难的是如何把它们组合成一个完整的程序。这恰好是C语言项目训练的核心价值：它逼着你学会抽象和模块化。你得先把现实世界的棋局抽象成数据结构，再把游戏规则抽象成函数，最后把用户交互抽象成一个循环。这个过程走通了，你对C语言的理解就完全不是刷几道练习题能比的。
从技术能力角度，这个项目至少覆盖了这些C语言知识点：数组（棋盘存储）、结构体（棋子走法）、函数指针（可选，做AI调度时很好用）、递归（搜索算法）、模块化编译（多文件组织）、指针传参（高效修改棋盘状态）。所以不管你是为了练手还是为了交作业，它的性价比都非常高。
1.2 什么人适合拿它当练手项目
如果你正好学完了C语言的指针和结构体，但还停留在写单个小功能的阶段，这个项目就是一个完美的进阶练习。它的难度曲线比较平滑：先做一个能双人对战的“走棋壳子”，不需要AI，代码量大概三四百行；再把规则判断补全，能判断将军和胜负，代码量到五六百行；最后加入简单的AI搜索，代码量会到千行左右。三个阶段你随时可以停下来，不会出现“没做完就烂尾”的挫败感。
如果你是准备课程设计，这个项目也比学生管理系统、图书管理系统这类常规选题有辨识度。老师看到“中国象棋”四个字，第一反应就是你下了功夫。更重要的是，这个项目有非常明确的验收标准：程序必须能正确执行象棋规则，必须能判定胜负，最好还能让人机对战。所有功能都是可演示、可测试的，答辩时不会没话讲。
2. 整体设计思路：动手前先想清楚这几件事
2.1 控制台版还是图形版：别一上来就碰图形库
每次有人问我做象棋要不要用EasyX或者SDL，我都会劝他：第一版绝对不要碰图形库。图形界面带来的额外复杂度——窗口事件、图片加载、鼠标坐标换算——和象棋逻辑本身是两回事，混在一起会让你分不清是规则写错了还是渲染画错了。控制台版本用字符打印棋盘，用坐标指令（比如e2 e4表示把e2位置的棋子走到e4）输入走法，完全能跑通所有逻辑。
等到逻辑部分全部稳定，你再考虑加图形界面。到时候把棋盘数组渲染成画面，就是一个数据到视图的映射问题，半天就能搞定。前期把精力放在逻辑上，收益最大。
2.2 模块怎么拆：让代码像搭积木一样清晰
一份能长期维护的中国象棋源代码，不能是单个几千行的main函数。我推荐的模块划分是这样：
- 棋盘模块（board.c）：负责棋盘数组的初始化、存取和显示。
- 走法模块（move.c）：负责枚举某个局面下的所有合法走法。
- 规则模块（rule.c）：负责判断将军、将死、困毙等局面状态。
- 人机模块（ai.c）：负责评估局面、搜索最佳走法。
- 主控模块（main.c）：负责组织游戏主循环，把上面几个模块串起来。
模块之间的依赖关系要尽量单向。比如走法模块只依赖棋盘模块，不依赖界面；规则模块依赖走法模块；AI模块依赖规则和走法模块。这样你在调试AI时，根本不会碰到界面代码；在改走法规则时，也不会影响AI逻辑。多人协作时，这种结构更是能明显减少冲突。
2.3 棋盘数据结构：用一维数组还是二维数组
中国象棋的棋盘是9列10行，一共90个交叉点。最直观的存储方式当然是二维数组int board[10][9]，可读性很好，board[row][col]直接对应坐标。但我个人更推荐一维数组int board[90]，索引用row * 9 + col换算。原因有两个：一是走子时方向遍历更方便，可以用一组方向偏移量push到每个方向；二是一维数组在递归搜索时要复制局面或悔棋，整体操作更简洁。
这里有个细节很多新手会踩坑：如果你用一维数组，一定要在访问棋盘前做边界检查，不然非常容易越界。可以先写一个带assert的宏来兜底，调试稳定后再去掉。
棋盘数组里存什么？我是这样约定的：0表示空，正数表示红方棋子，负数表示黑方棋子，每个数字对应一种棋子类型。比如1红帅、2红车、3红马、4红炮、5红象、6红士、7红兵；黑方就是对应的负值。这个编码方式简单直观，打印时用switch转成汉字就行。
3. 棋盘与棋子的核心实现
3.1 初始化棋盘：把开局局面写进数组
开局时红黑双方各16个棋子，位置是固定的。我一般用一个字符串表示的初始化数组，然后用一个循环把字符转换成数字存进棋盘：
void init_board(int board[]) { // 用一个简化的字符串布局初始化 // 红方在下，数组行0是黑方底线 const char* layout[10] = { "rheakaehr", // 黑方第二行：车马象士将士象马车 ".........", // 空行，实际这里应该是卒位等 ".........", // 这里按真实规则补充 ".........", ".........", ".........", ".........", ".........", ".........", "RHEAKAEHR" // 红方底线 }; // 这里需要对army的字符做映射转换 }初始化这部分不涉及算法，但很容易写烦。建议把字符映射逻辑单独写一个函数char_to_piece(char c)，比如'R'对应红车2，'r'对应黑车-2，这样以后要改动局面试棋很方便，直接改字符串就行。
3.2 马的规则细节：蹩马腿怎么判断
象棋里马是最容易被写错的棋子。马走“日”字，有8个落点，但每个落点都有一个“蹩腿位置”。以向左上方跳为例，落点是(row-2, col-1)，蹩腿位置是(row-1, col)——也就是马当前所在位置的正上方那个点。如果这个点有棋子（不管是哪一方的），马就不能向左上跳。
代码里最好的做法是预定义两组平行数组，一组存落点偏移，一组存对应的蹩腿偏移：
// 马的8个方向：dr表示行偏移，dc表示列偏移 // 每行是一个方向的“落点偏移”和“蹩腿偏移” static const int horse_move[8][4] = { {-2, -1, -1, 0}, // 左上 {-2, 1, -1, 0}, // 右上 {-1, 2, 0, 1}, // 右二上一 { 1, 2, 0, 1}, // 右二下一 { 2, 1, 1, 0}, // 右下 { 2, -1, 1, 0}, // 左下 { 1, -2, 0, -1}, // 左二下一 {-1, -2, 0, -1}, // 左二上一 };判断逻辑就是三件事：落点是否越界、落点是否是己方棋子、蹩腿位置是否有棋子。这三点都通过了，这一步才合法。把数组设计成一行一组的格式，不仅代码紧凑，也避免了两组偏移量对应错位的经典bug。
3.3 炮的规则：移动不吃子，吃子要隔一个
炮是中国象棋里最特殊的棋子。它移动的时候和车一样，横竖直线走，中间不能有棋子；但它吃子的时候，中间必须恰好有一个棋子作为“炮架”。这就意味着，判断炮的走法要分成两段逻辑：先沿四个方向扫描，遇到第一个棋子前，所有空格都是合法移动位置；遇到第一个棋子后，继续往下扫，遇到的第二个棋子如果是对方棋子，就是合法的吃子位置，然后这个方向就结束了。
炮的规则在走法生成器里容易写得冗长，但逻辑上并不复杂。建议用一个独立函数generate_cannon_moves单独处理，不要和车的逻辑混在一起，因为一个允许走一个不允许吃子的行为差异很大。
3.4 走法生成器的统一接口
上面说到规则分散在各处，但最终要用一个统一的函数把它们串起来。我推荐的接口是：
typedef struct { int from; int to; } Move; int generate_moves(int board[], int side, Move moves[]);side表示当前是哪一方，1为红方，-1为黑方。函数内部遍历board，遇到当前方的棋子就调用对应的棋子走子函数，把所有合法走法写入moves数组，最后返回走法数量。这个接口设计是整个项目的关键，后面的规则判断和AI搜索都建立在它之上。它让“某个局面下有哪些选择”这个问题变得非常清晰。
4. 规则判定与胜负逻辑
4.1 将军判断：反向检查比正向枚举更高效
判断当前方是否被将军，常见做法是找到己方老将的位置，然后看这个位置是否被任何对方棋子攻击。如果写成“枚举对方所有棋子的所有走法，再看有没有吃老将”，虽然也能工作，但会造成大量重复计算。更优雅的方式是“反向攻击查询”：对老将位置，沿着车的四条线找炮架，沿马的方向查可能的马腿位置，沿炮的线找中间棋子数量，直接判断有没有对应的攻击者。
这个查询写起来会稍微绕一点，但它是后面AI搜索的性能关键。因为在搜索树里，每个节点都要判断是否将军，如果每次都枚举走法，搜索速度会慢很多。反向检查把常数时间降下来了，AI的深度才能往上加。
4.2 将死与困毙：统一用一个终局函数判断
中国象棋的终局判断包含两个不同情况：将死是“被将军且没有任何合法走法解围”；困毙是“没被将军但一个子都走不动”。这里有个容易搞混的点：国际象棋里困毙算和棋，中国象棋里困毙算输。写程序时要明确：只要某方合法走法数量为0，游戏就结束——被将军则对方赢，没被将军则当前方输。
实现上，我建议把所有判断都收敛到一个函数里：
// 返回值：1表示红胜，-1表示黑胜，0表示棋局继续 int check_game_over(int board[], int side) { Move moves[MAX_MOVES]; int cnt = generate_moves(board, side, moves); if (cnt > 0) return 0; int in_check = is_in_check(board, side); if (in_check) return -side; // 被将军且无棋可走，对方获胜 return -side; // 困毙，当前方输 }注意这里把两种情况都判定为负，逻辑上是正确的。不过实际对局中困毙很少见，所以很多简化版程序只处理将死，也不会出大问题。
4.3 长将和重复局面的简化处理
完整棋规里还有长将、长捉、一将一闲等循环判负规则，实现起来要做历史局面记录和重复检测，复杂度明显上升。我建议第一版完全不管这些，只规定“不许走会导致对方老将正对着己方老将的棋”，也就是将帅不能照面的规则必须单独处理，但长将循环就让双方来回走。毕竟AI层数浅的时候也不太会主动长将，新手对战更加遇不到这种问题。先把主体功能做完，比追求规则完整更重要。
5. 人机对弈：让电脑帮你走棋
5.1 评估函数：最简单的“局面好坏”算法
想让电脑会下棋，得先让它“知道”什么局面好。最基础的评估函数就是子力价值求和：车约900分，马400分，炮450分，士象各120分，兵在开局到残局价值从100变化到200左右。为了让电脑不是单纯“贪吃”，还需要给每个棋子加一张位置价值表。
比如马的位置价值表，会告诉程序“马在河边、在对方阵地内价值更高，在边角被憋住价值低”。这个表可以手写，网上也有经典象棋的开源位置表可以借鉴。实现时通过查表算出每个棋子的位置加分，代码量不大，但对AI棋力的提升非常明显。
int evaluate(int board[]) { int score = 0; for (int i = 0; i < 90; i++) { int piece = board[i]; if (piece > 0) { score += piece_value[piece] + pos_table[piece][i]; } else if (piece < 0) { score -= piece_value[-piece] + pos_table[-piece][89 - i]; } } return score; }89 - i是个小技巧：因为棋盘上下对称，黑方视角下位置价值可以直接镜像复用红方的表，省掉一套黑方专用表。
5.2 极小化极大搜索：让电脑往后多想几步
评估函数只能看眼前，真正的棋力来自搜索。极小化极大搜索的思路是：红方要选分数最高的走法，黑方要选分数最低的走法，轮流递归。搜到指定深度后，用评估函数给叶子节点打分，往回一层层取最大或最小值。
这个逻辑直接用递归实现。再加上alpha-beta剪枝——也就是当某一分支已经明显不如已有最优解时，直接剪掉后面的搜索，搜索效率能提升好几倍。初版先写一个深度3的搜索，棋力就很可观了。调试时可以打印每一步AI算出的最佳分数和对应的走法，观察它的思考过程，也方便定位bug。
5.3 搜索优化的几个实用小技巧
一是走法排序：先在当前走法里把能“吃大子”的走法排在前面，alpha-beta剪枝的效率会大幅度提升。二是历史表或置换表这种高级优化暂时可以不用，新手阶段没必要把搜索做到很复杂。三是每次搜索前复制一份棋盘，用“试走-评估-回退”的方式，千万不要在递归里直接修改全局棋盘，否则很容易因为忘了恢复而导致局面错乱。
我自己的经验是：先实现深度3的搜索加上评估函数，跑几盘看看AI会不会主动将军、会不会吃子、会不会被将死时逃跑。这个阶段把AI从“完全不会下”调到“能走几步像样的棋”，比追求全胜重要得多。
6. 完整代码组织与工程化建议
6.1 文件结构：从第一天就分文件写
不要等代码写到几百行再拆文件，从最早开始就按模块分文件。我推荐的项目结构是这样的：
chess/ ├── main.c // 程序入口，游戏主循环 ├── board.c // 棋盘初始化、打印 ├── board.h ├── move.c // 走法生成 ├── move.h ├── rule.c // 将军、终局判断 ├── rule.h ├── ai.c // 评估与搜索 ├── ai.h ├── Makefile └── README.md头文件里只放需要跨文件暴露的接口和常量，内部辅助函数用static修饰，避免外部误调用。这样做的好处是：编译错误能快速定位到文件，多人协作不冲突，代码阅读成本也低。更重要的是，它会逼着你从第一天就用“模块”而不是“一大坨函数”来思考问题。
6.2 开发顺序：先做双人版，再加AI
我强烈建议把项目分成三个阶段：
第一阶段，先实现双人控制台对战。红方输入起始坐标和目标坐标（比如e2 e4），程序校验走法合法性，然后切换轮到黑方。这个阶段不写AI，不写搜索，只把规则和交互跑通。你可以自己和自己下，也可以找朋友在同一个终端来回输入。
第二阶段，补全将军和终局判断。下棋过程中如果将军了，程序要提示；出现将死或困毙，程序要结束对局。
第三阶段，把AI模块接进来，让人机对战。红方位置换成AI走棋，玩家扮演黑方或红方。
这个顺序最重要的意义是：每个阶段都能跑、能测、能看效果。bug不会一下子积累太多，排查起来容易得多。
6.3 Makefile与编译要点
给项目配一个Makefile，比每次手动敲gcc main.c board.c move.c rule.c ai.c -o chess要省心得多：
CC = gcc CFLAGS = -Wall -O2 OBJS = main.o board.o move.o rule.o ai.o chess: $(OBJS) $(CC) -o chess $(OBJS) clean: rm -f *.o chess-Wall会显示所有警告，很多低级错误在编译阶段就能暴露。-O2优化对AI搜索性能有明显帮助。如果编译报“undefined reference”，大概率是某个函数声明了但没实现，或者链接时漏掉了某个.o文件。养成编译一次解决所有问题的习惯，到后面调逻辑时你会感谢自己。
7. 常见问题与排查技巧：这些坑我替你踩过了
7.1 程序一运行就崩溃，八成是数组越界
一维棋盘board[90]如果访问board[row * 9 + col]时row或col越界，程序不会马上报错，而是随机篡改内存，表现就是“某些棋子莫名其妙消失了”或者“程序直接卡死”。我的排查经验是：在调试阶段，给所有访问棋盘的位置加断言assert(r >= 0 && r < 10 && c >= 0 && c < 9)，跑一遍对局，断言会精确告诉你是哪一步越界了。找到问题后再把断言去掉，不影响性能。
7.2 车轮子能隔着棋子飞：走法生成时忘了检查中间阻挡
车的走法最容易写漏的是“中间不能有棋子”。我调试时碰到过一次：AI走出了从a0直接斜着吃掉b1的怪棋，后来发现是方向遍历代码里少了一个break——扫描到一个棋子后应该继续检查该方向上是否还有能吃掉的子，但写成了立刻停止。修正逻辑后，车和炮的行进扫描都要反复测试，特别是“炮隔山打子”这种半路遇到第一个棋子再继续找炮架的情况。
7.3 AI走棋太蠢：先看评估函数，再看搜索深度
如果AI总是白送大子或者看不出被将军，不要先怀疑搜索算法，先检查评估函数。最简单的测试方法：用同样的局面，让AI连续走两步，打印每一步的评估分值。如果分值出现剧烈波动，说明评估函数有问题；如果分值一直很稳定但AI还是下得差，那可能是搜索深度太浅。我自己调AI时，通常从深度2开始，确认评估合理后再加到3，深度4配合剪枝已经能在普通电脑上秒出了。
7.4 走法校验漏了“自己吃自己”
这是一个非常常见但不难解决的问题。建议把所有棋子的落点检查统一收口到一个公共函数is_valid_target(board, to, side)里：目标位置为空或者对方棋子时合法，己方棋子非法。不要在车、马、炮各自的规则里分别写判断，那样容易重复出错。收口之后，规则逻辑会很清晰，后续加新规则也不容易乱。
最后再分享一点个人体会
做这个项目的过程，其实就是一个把“好像懂了”变成“真的能写出来”的过程。很多人学C语言卡在语法和习题之间，缺的正是这么一个有完整逻辑链、能独立运行、还能不断迭代的小项目。中国象棋的规则复杂度刚刚好：太简单练不出架构能力，太复杂又容易劝退。做完这个项目再回头看指针、数组、递归，你会发现它们不再是孤立的语法点，而是搭建整个程序的工具。
如果身边有朋友也在学C语言，我特别建议你们组队做这个项目。一个人负责棋盘和走法，另一个人负责AI搜索，最后联调时互相找bug，这种体验能提前让你感受到真实开发的节奏。后续想扩展的话，可以试试给AI加开局库、做命令行悔棋、或者接一个简单的图形界面。起点就是这棵象棋程序的小树苗，长成什么样完全看你想往哪个方向浇水。
本文还有配套的精品资源，点击获取
