Swing贪吃蛇需用Timer控制主循环并确保EDT绘图，统一格子坐标建模，聚焦面板处理方向键，暂停仅设标志位，重启调用resetGame重置状态。
Swing 绘图刷新不及时，蛇身残影或卡顿
Swing 的 paintComponent() 不是“每帧重画”，而是由系统调度触发，手动调用 repaint() 也不保证立刻执行。贪吃蛇这种高频更新场景下，容易出现移动延迟、拖尾或闪烁。
- 必须在独立线程中控制游戏主循环（不能在 EDT 中
Thread.sleep()），推荐用javax.swing.Timer而非Thread.sleep()+repaint()：它自动确保回调在 EDT 执行，且节拍稳定 - 在
paintComponent(Graphics g)开头加super.paintComponent(g)，否则旧画面残留；别用getGraphics()直接绘图——那是临时对象，不可靠 - 避免在
paintComponent里做计算或 IO，只负责“把当前状态画出来”。蛇身坐标、食物位置等数据应由游戏逻辑线程提前算好并存为成员变量
键盘监听失效或方向响应错乱
Swing 默认不捕获全局按键，KeyListener 必须绑定到「有焦点且可聚焦」的组件上，而 JFrame 默认不可聚焦，JPanel 默认也不请求焦点。
- 给绘制面板（继承
JPanel的类）调用setFocusable(true)，并在初始化后立即调用requestFocusInWindow() - 用
KeyAdapter重写keyPressed即可，不用管keyReleased或keyTyped；贪吃蛇禁止 180° 反向（比如正右时按左键无效），得在事件里判断：if (!(newDir == LEFT && currentDir == RIGHT) && ...) - 连续按键时，系统可能触发重复
KEY_PRESSED，但贪吃蛇只需方向变更一次，建议用布尔标记“本次循环已处理方向”，或直接以最后一次有效按键为准
蛇身碰撞检测总不准，吃到食物后没变长
核心问题常出在坐标抽象和边界对齐上：Swing 坐标是像素级，但贪吃蛇通常用“格子”建模（如每格 20×20 像素）。若直接用像素坐标做碰撞，会因四舍五入或偏移导致误判。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 统一用“格子坐标”管理逻辑：蛇头位置存为
int x, int y（单位：格），绘制时再乘以格子大小（如x * GRID_SIZE）；食物位置也按格生成，用new Random().nextInt(width / GRID_SIZE) - 碰撞检测分两类：撞墙（
x = width / GRID_SIZE）和撞自己（遍历蛇身，跳过头部，检查是否有格子坐标重合） - “吃食物变长”不是“画多一节”，而是往蛇身
List<point></point>末尾添加一个与尾部相同坐标的Point，下一帧移动时，尾部不动，其他节往前挪——这样逻辑清晰，不易漏帧
游戏暂停/重启后状态混乱，计分归零或蛇速异常
暂停不是停止线程，而是让主循环跳过更新逻辑；重启也不是重新 new 对象，而是重置关键状态变量。很多初学者在这里直接 timer.stop() 后又 timer.start()，却忘了清理方向、蛇身列表、食物位置等。
立即学习“Java免费学习笔记（深入）”；
- 定义清晰的状态变量：
boolean isRunning、boolean isPaused、int score、List<point> snakeBody</point>、Point food；所有重置操作集中到一个resetGame()方法里 - 暂停时仅设
isPaused = true，主循环里用if (!isPaused) { update(); }控制；不要调用timer.stop()，否则恢复时需重新配置 delay - 重启前必须清空
snakeBody并重建初始蛇（如三节，起始坐标居中），重新生成food，重置score = 0和direction = RIGHT；否则残留旧数据会导致越界或空指针
最易被忽略的是：Swing 绘图和游戏逻辑共享同一套坐标模型。一旦混用像素和格子、或在不同线程里修改同一 List，不出错才怪。宁可多一层封装，比如用 class Position { int x; int y; }，也别裸用 int[] 或 Point。
