做C语言课程设计，选了最经典的扫雷项目。
本来以为逻辑很简单：两个棋盘、布雷、计算周围雷数、判断输赢，结果从中午写到下午，跟bug死磕了大约2个小时。最离谱的是：我明明设置了80个雷用来检验程序，运行出来数来数去都不对，最后发现居然是自己手滑写错了一个字母。
写这篇博客，记录一下这次踩坑全过程，也给后面做扫雷的同学避避坑。
一、项目整体思路
扫雷的核心结构其实很清晰：
1. 用两个二维数组，一个存雷（mine），一个给玩家显示（show）
2. 为了防止边缘坐标越界，数组多开一圈边界
3. 随机布雷，保证不重复
4. 点击坐标后，计算周围8个格子的雷数
5. 判断输赢，踩雷即结束
二、正常流程都没问题
初始化、打印棋盘、计算雷数这些都比较顺利。
周围雷数直接利用字符ASCII差值计算，代码也很简洁：
布雷函数也按标准逻辑写的
三、最崩溃的问题：80个雷去哪了？
运行之后我人傻了：
设置80个雷，打印雷盘一数，明显不够。
我开始疯狂排查：
- 是不是随机数重复了？
- 是不是初始化没做好？
- 是不是打印函数少打了？
- 是不是越界了？
对着代码看了一遍又一遍，逻辑都没问题，可雷就是少了。
四、最终找到bug：我多写了一个S
排查到最后，我终于发现问题所在：
我在 SetMine 里，把参数 ROW 写成了 ROWS！
本来应该传 9，结果传成了 11，导致随机坐标生成到了 1~11 的范围。
而我打印棋盘只打印 1~9，第10、11行的雷全部“隐形”了，所以数出来永远不对。
就这么一个字母，卡了我快一个小时。
改完之后瞬间正常，80个雷整整齐齐出现在棋盘上。
五、总结与收获
这次写扫雷真的让我印象深刻：
1. 编程细节真的太重要，一个字母就能让程序完全跑偏
2. ROW / ROWS、COL / COLS 一定要分清楚，非常容易写错
3. 遇到bug不要慌，一步步定位，大概率都是低级错误
4. 调试比写代码更重要，多看调用关系、参数传递
虽然过程很崩溃，但改完跑通的那一刻还是很有成就感。
把这段经历发出来，希望大家别再踩我这个坑。