企业官网建设流程全解析

简介：这是一套面向Java课程设计与毕业设计的坦克大战游戏开发资料包，基于Swing技术实现，适合计算机专业学生用于毕设参考、课程作业或项目实战。压缩包采用rar格式，约1.46MB，主要包含毕业论文、Java源代码与答辩PPT三类核心材料，文件整体规模虽小，但内容覆盖系统分析、概要设计、详细设计、编码实现与测试总结等完整开发环节。资源已有582人学习浏览，流程描述较为完整：从可行性分析中的技术与经济判断，到需求分析明确游戏核心功能，再到工作流程图、项目规划、开发与运行环境说明，构成清晰的前期设计脉络；详细设计部分则围绕游戏主窗口和游戏数据输出模块展开，涉及游戏元素绘制与信息显示等关键实现；测试部分还提供了硬件环境与测试结果分析。借助这套资料，读者既能学习Java Swing游戏开发的整体思路，也能获得从论文撰写到答辩展示的一体化参考，尤其适合需要快速上手同类项目的毕业生或初级开发者。

1. 从课设到毕设：基于java的坦克大战游戏的开发设计与实现这个题目，现在做依然不吃亏

很多人觉得坦克大战是老掉牙的题目，但把它当成一个完整的“开发设计与实现”来做，它正好覆盖了 Java 课设和毕设最常被追问的几个考点：多线程、事件监听、碰撞检测、对象建模、界面刷新。你不需要引入任何重型框架，只用标准 JDK 的 Swing 就能跑出一个可玩的游戏，这本身就是难得的“低成本高收益”。如果你正在找 java 课程设计案例源码方向，这个题目是比图书管理、学生选课系统更值得投入的一个，因为它的难点不在“写功能”，而在“怎么把实时程序的结构设计对”——这也是答辩时老师最愿意追问的地方。下文我会按我自己带这种项目时的顺序来讲：先想清楚设计，再落代码，最后把坑和答辩准备一起补齐。

2. 先立住设计再写代码：把坦克大战拆成可被答辩追问的对象模型与线程模型

2.1 为什么是 Swing 双缓冲，而不是 JFrame 裸画或 JavaFX

做游戏界面，第一反应是用 JFrame 加 paint 方法直接画。但坦克大战每秒要刷新几十次坦克、子弹、墙壁，如果直接在 JFrame 上作画，屏幕会闪烁得像放老式幻灯片。Swing 的 JPanel 默认开启了双缓冲，绘制过程先在后台缓冲区完成，再一次性复制到屏幕，这就是画面稳定的关键。JavaFX 也能做，性能更好，动画系统更完善，但它的学习曲线和答辩风险都更高——老师追问“你的事件分发线程怎么设计的”时，Swing 的 EDT（Event Dispatch Thread）模型要比 JavaFX 的 FXAT 更容易讲清楚。我一般建议：课设和毕设选 Swing，把精力放在游戏逻辑和对象模型上，而不是花时间折腾场景图和动画 API。

JFrame 裸画还有一个问题：它没有一个独立的绘制回调结构，你得自己管理所有组件的重绘时机，很容易写出“一堆 if 塞在 paint 里”的代码。JPanel 配合paintComponent(Graphics g)让你每次刷新只画当前帧，逻辑清晰，也方便后续加菜单、计分板、暂停界面。

2.2 用面向对象组织坦克、子弹、地图：继承与接口的取舍

坦克大战里至少有三类“会动的东西”：玩家坦克、敌方坦克、子弹。它们都有坐标、速度、方向、移动行为，但敌方坦克还有自动转向和开火策略。如果用继承，可以抽一个BaseTank抽象类，把公共的移动、转向、绘制逻辑放进去；玩家和敌人各自实现自己的行为接口。这里有同学会纠结：是不是所有东西都往继承树上挂？不用。地图里的墙壁是静止对象，碰撞属性完全不一样，硬塞进坦克继承树只会让代码变扭。

我一般这样划分职责：

接口在这里的最大价值是解耦“行为策略”和“具体坦克”。比如定义一个IMoveStrategy，玩家坦克传入KeyMoveStrategy，敌方坦克传入AutoMoveStrategy，这样新增一种敌人只需要新写一个策略类，不用改动坦克本体。答辩时这个设计点很加分，因为这体现了面向对象编程 Java 里的“开闭原则”：对扩展开放，对修改关闭。

代码落地时有一个参数需要先拍板：地图格子和坦克尺寸。我一般用 600×600 的游戏区，32×32 的格子，坦克占一个格子，子弹直径 8 像素。这样地图数据用一个二维数组就能表达，碰撞计算也简单。如果把坦克设成 30×30 这种非整数尺寸，虽然也能跑，但地图对齐会多出很多取整的边界判断，不值当。

2.3 线程模型：把游戏循环、绘制、事件监听分清楚

坦克大战常见的翻车写法是开一个new Thread(() -> gameLoop())然后在里面直接调repaint()。这样能跑，但会有两个隐患：一是这个线程和 Swing 的 EDT 并发操作组件，容易出现间歇性界面卡死；二是事件监听（键盘）和游戏循环之间没有明确的“生产-消费”关系，按键命令直接被写到坦克坐标上，线程间数据一致性问题会让你查到头秃。

我一般会把线程分成两层。第一层是 Swing 的javax.swing.Timer，每 16 毫秒触发一次actionPerformed，在这个方法里统一更新游戏状态并调用repaint()。因为Timer的回调运行在 EDT 上，所有界面修改都回到了同一个线程，天然避开了并发修改问题。第二层是给 AI 用的独立线程：如果敌方坦克的行为计算很重，或者你想模拟“同时思考”，可以开一个ScheduledExecutorService专门算决策，算出结果写进一个BlockingQueue，主循环从队列里取指令执行。

这里要特别说明一个容易被误用的点：Swing Timer的 16 毫秒并不保证 60 FPS。如果你的逻辑计算超过 16 毫秒，实际帧率会掉下去。所以我通常不写死“60帧”这个概念，而是说“帧率上限约 60 FPS”，并且把碰撞检测和 AI 开销控制在每帧 5 毫秒以内，留下余量。

public class GamePanel extends JPanel implements ActionListener { private Timer gameTimer; private List<Bullet> bullets; private PlayerTank player; private boolean isRunning; public GamePanel() { setPreferredSize(new Dimension(600, 600)); setFocusable(true); bullets = new ArrayList<>(); // Timer 的第二个参数是监听器，第三个参数（毫秒）决定帧率上限 gameTimer = new Timer(16, this); } public void startGame() { isRunning = true; gameTimer.start(); } @Override public void actionPerformed(ActionEvent e) { if (!isRunning) { return; } // 这一帧里只做“状态更新”，不做界面绘制 updateGameState(); // repaint 会触发后面的 paintComponent，完成真正绘制 repaint(); } @Override protected void paintComponent(Graphics g) { super.paintComponent(g); drawMap(g); for (Bullet bullet : bullets) { bullet.draw(g); } player.draw(g); } }

这段代码的核心逻辑是：actionPerformed只负责推进游戏状态，paintComponent只负责把状态画出来，两件事严格分离。参数16就是 1000/16 约等于 62 FPS 的刷新间隔。如果电脑配置较低，可以把 16 改成 33，帧率降到 30 FPS，游戏的响应感会明显变肉，但对课设演示来说可以接受。真正要注意的是不要把复杂计算塞进paintComponent，否则会导致 EDT 阻塞，界面直接卡住。

3. 手把手把核心功能写出来：游戏主循环、碰撞检测与敌方 AI 的落地实现

3.1 初始化地图与坦克实体：尺寸、速度、初始位置的参数设置

地图是坦克大战的地基。我习惯用一个二维数组表示地图，0 代表空地，1 代表砖墙，2 代表钢墙，3 代表基地。每格的像素尺寸由TILE_SIZE = 32决定。这样设计的好处是：地图编辑不依赖可视化工具，直接改数组就能换一关，后续扩展地图文件做存档也很方便。

public class MapManager { public static final int TILE_SIZE = 32; public static final int MAP_WIDTH = 600 / TILE_SIZE; // 约 18 格 public static final int MAP_HEIGHT = 600 / TILE_SIZE; // 约 18 格 private int[][] mapData = { {0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0}, {0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0}, // 其余行省略，实际用循环初始化 }; public boolean isWall(int tileX, int tileY) { if (tileX < 0 || tileX >= MAP_WIDTH || tileY < 0 || tileY >= MAP_HEIGHT) { return true; } return mapData[tileY][tileX] == 1 || mapData[tileY][tileX] == 2; } }

这段代码里我用了二维数组，重点不是内容，而是提供isWall这样的查询接口，让碰撞检测模块不再直接依赖地图的内部结构。参数上要注意：边界判断必须放在数组访问之前，否则越界异常会直接打断游戏循环。我遇到过很多同学把地图数组定义成int[][]后就开始在界面里硬编码坐标，后续想加障碍物就得改一大片代码。正确的做法是所有格子坐标都从像素坐标换算而来，映射公式是tileX = pixelX / TILE_SIZE，反向则是pixelX = tileX * TILE_SIZE。

坦克初始位置也需要单独设定。玩家坦克一般出生在地图左下角，敌方坦克出生在左上、中上、右上三个固定点。出生点检查很容易漏：如果出生点正好有障碍物或敌方坦克已经占用，坦克就会互相卡死。我一般保留一个List<Point> spawnPoints，每次生成敌人前先检查周围是否有存活坦克，再决定是否延迟生成。这个判断叫“出生点清场”，是很多半成品项目直接忽略的细节，但答辩演示时如果在出生点撞出一团乱麻，观感很差。

3.2 子弹移动与碰撞判定：像素级矩形相交与越界回收

子弹是整个游戏里最容易出 bug 的对象，因为它的速度和坦克不一样，每秒移动的像素更多，碰撞检测的频率跟不上。很多人的写法是每次移动后检查“当前矩形是否与墙壁相交”，但当子弹速度超过墙壁厚度时，就会发生理论上的“穿透”——上一帧子弹还没到墙，这一帧已经越过墙了，中间没有被检查到。这个现象我后面会展开讲。这里先说标准解法：把“移动”和“碰撞”分开，碰撞时用上一帧位置和当前帧位置联合成的轨迹矩形来判定。

public class Bullet { private int x, y; private final int speed = 8; private Direction direction; private boolean alive = true; public void move() { int prevX = x; int prevY = y; switch (direction) { case UP -> y -= speed; case DOWN -> y += speed; case LEFT -> x -= speed; case RIGHT -> x += speed; } // 记录轨迹矩形，防止高速穿透 trajectoryRect = new Rectangle( Math.min(prevX, x), Math.min(prevY, y), Math.abs(x - prevX) + BULLET_SIZE, Math.abs(y - prevY) + BULLET_SIZE ); } }

这里的核心参数是speed = 8，也就是每帧子弹移动 8 像素。用轨迹矩形时，即使子弹一帧从墙的一侧跳到另一侧，碰撞判定用的也是整个移动路径扫过的区域，不会漏判。速度调得越快，轨迹矩形的宽度越大，碰撞判定越保守。这个方式比“把速度限制在墙壁厚度以内”更通用，因为游戏里子弹和坦克的尺寸差很多，一味限速会让子弹慢得像蜗牛。

子弹越界回收也是常见遗漏点。子弹飞出 600×600 边界后如果不移除，ArrayList会越攒越多，界面不崩但内存一直涨，运行十分钟后明显掉帧。回收逻辑放在主循环里，遍历时用Iterator删除，避免并发修改异常。

public void updateBullets() { Iterator<Bullet> it = bullets.iterator(); while (it.hasNext()) { Bullet bullet = it.next(); bullet.move(); // 出界、撞墙、命中坦克都算“死亡” if (bullet.isOutOfBounds() || bullet.hitWall(mapManager)) { it.remove(); } } }

使用Iterator.remove()而不是list.remove(bullet)的原因是：遍历过程中直接删除元素会让ArrayList抛出ConcurrentModificationException。这个错误极其常见，而且只在特定帧数下出现，属于典型的“玄学 bug”。用迭代器删除是从根源上避开问题。

3.3 敌方坦克 AI：伪随机转向、开火间隔与边界约束

敌方 AI 不需要做得多聪明，但要有“像在思考”的感觉。常见做法是给每辆敌方坦克两个计时器：移动计时器和开火计时器。每帧检查计时器是否到期，到期就随机换方向或开火。为了让游戏可玩性不崩，开火间隔要加随机扰动，不能所有敌人同一帧开火，否则屏幕上瞬间全是子弹。

public class EnemyTank extends BaseTank { private int thinkInterval = 50; // 每 50 帧思考一次 private int thinkCountdown = thinkInterval; private Random random = new Random(); public void update() { thinkCountdown--; if (thinkCountdown <= 0) { thinkCountdown = thinkInterval + random.nextInt(30); // 随机选择方向或开火 if (random.nextBoolean()) { this.direction = Direction.values()[random.nextInt(4)]; } else { fire(); } } move(); } }

这段 AI 的逻辑是：50 帧为一个思考周期，到期后 30% 概率转向、30% 概率开火、其余时间继续直行。thinkCountdown归零后重置为thinkInterval + random.nextInt(30)，这样每个敌人的行为节奏有差异，游戏不会显得机械。参数调优时可以改thinkInterval：数值越小敌人反应越快，适合做困难关卡；数值越大敌人越“呆”，适合开局关卡。

边界约束是 AI 绕不开的坑。如果敌方坦克撞墙后不处理，它会一直尝试朝墙移动，表现就是卡在墙边抖动。我一般给move()一个返回值boolean moved，撞墙时返回 false，然后立即强制换向。这是最简单的“感知-决策”模型，不需要任何路径搜索算法，但对课设来说已经足够。答辩时你可以主动提一句“如果要进一步做智能，可以用 BFS 寻路”，这相当于给自己挖了一个能回答的知识扩展点。

4. 避坑与常见问题排查：子弹穿透、按键失灵、画面闪烁的定位与修复

4.1 画面闪烁严重：双缓冲失效的典型症状

现象：运行游戏后，坦克和子弹移动时屏幕有明显闪烁，像老式 CRT 显示器刷新率不够。原因：在继承JPanel后重写了update(Graphics g)方法，并且没有调用super.update(g)，导致 Swing 内置的双缓冲机制被绕过了。解决：不要重写update，所有绘制都放在paintComponent里即可。如果你在写代码时确实需要在每帧绘制前清屏，用g.clearRect而不是重写update。这是一个很隐蔽的坑，因为你可能会为了“解决闪屏”去查各种双缓冲教程，最后发现是自己在自定义绘制里破坏了默认机制。

还要检查一点：是否在paintComponent里创建了新的Graphics2D对象。有些教程教人Graphics2D g2 = (Graphics2D) g.create()，用完没有dispose()，这会逐步耗尽系统图形资源，跑几分钟后整个绘制变得卡顿。正确的做法是直接用传入的g，或者在使用create()后 finally 里释放。

4.2 子弹穿透墙壁或坦克：高速物体的边界误判

现象：子弹在高速移动时偶尔会直接穿墙而过，或者在敌人密集时穿过坦克而没有命中判定。原因：子弹每次移动 8 像素，如果墙壁只有 2-3 像素厚，子弹“上一帧在墙前、这一帧在墙后”，当前位置的矩形和墙壁完全没有交集。解决：按上文 3.2 里的轨迹矩形做碰撞检测，把移动前后的像素范围合并成一个矩形再判断。这是游戏开发里最典型的“隧道效应”（tunneling），很多人第一反应是限制子弹速度，但没有根治问题。

另一个隐蔽原因是碰撞检测用的是“中心点”而不是“矩形”。如果你写的是Math.abs(bulletX - tankX) < 5这类距离判断，当两个物体移动交错时很容易漏判。统一改成Rectangle.intersects()后，碰撞判定就稳定了。我还会在调试模式下把轨迹矩形画出来，你能直观地看到碰撞范围是不是比物体大了一圈，这个可视化排错方法比打日志快得多。

4.3 按键失灵与“粘键”现象

现象：按下方向键后坦克只动了一下就停了，或者按住前进再按左右时，坦克停在原地不动。原因：键盘监听写在了keyPressed里直接修改坦克坐标，而当时按下另一个键时，事件顺序被打乱，导致某个方向键的keyReleased没被触发，坦克误以为该方向还在按住。解决：不要用“按下就动”的事件处理模型，改用“按键状态集合”。

public class KeyHandler extends KeyAdapter { private Set<Integer> pressedKeys = new HashSet<>(); @Override public void keyPressed(KeyEvent e) { pressedKeys.add(e.getKeyCode()); } @Override public void keyReleased(KeyEvent e) { pressedKeys.remove(e.getKeyCode()); } @Override public void focusLost(FocusEvent e) { // 窗口失焦时清空按键状态，防止“粘键” pressedKeys.clear(); } public boolean isKeyDown(int keyCode) { return pressedKeys.contains(keyCode); } }

这段代码的关键点是focusLost里清空集合。如果你玩着玩着点了一下另一个窗口，再切回来时按键容易“卡住”，就是这个原因。pressedKeys用HashSet是因为它的contains操作是 O(1)，键盘状态是高频读取，用数组或ArrayList也够，但HashSet更语义化。主循环里移动坦克时只读取isKeyDown(KeyEvent.VK_LEFT)，不再直接把事件里的键码映射到某一次移动，这样就算事件丢了一个keyReleased，也不会导致永久卡键。

4.4 敌方坦克集体静止：线程同步的黑匣子

现象：游戏开始后，玩家坦克能正常移动，但所有敌方坦克“发呆”不动，有时一局游戏里有几辆敌坦从头到尾没开过火。原因：最常见的是ConcurrentModificationException被catch后吞掉了，错误堆栈被打印到控制台但你没注意，程序继续运行但 AI 线程已经死亡。另一个原因是两个线程同时修改了List<EnemyTank>，导致迭代中断。解决：给 AI 的逻辑加独立保护，或者在主线程中统一更新。

// 错误示范：AI 线程直接改共享 List ExecutorService aiPool = Executors.newFixedThreadPool(4); for (EnemyTank enemy : enemies) { aiPool.submit(() -> enemy.update()); // 多线程同时写 enemy } // 正确做法：AI 线程只算“决策”，主循环统一更新状态 public void updateEnemies() { for (EnemyTank enemy : enemies) { enemy.setNextDecision(aiDecider.decide(enemy)); enemy.applyDecision(); } }

这个坑的排查成本很高，因为你看到的现象是“敌坦不动”而不是“程序报错”。处理原则是：游戏状态更新只允许一个线程写，其他线程最多提供输入。用ScheduledExecutorService做 AI 计算没问题，但计算结果要通过queue传给主循环，不能在子线程里直接调用enemy.move()。这条血泪经验我每次带项目都会强调一次——多线程游戏最容易翻车的不是算法，而是状态共享的边界没划清楚。

5. 让项目经得起答辩和面试：测试、日志与 PPT 制作要点

5.1 用 JUnit 给碰撞检测写可回归的单元测试

很多同学觉得游戏没法单元测试，因为“画面一直在变”。但碰撞检测、移动约束、边界判定这些都是纯逻辑，完全可以从界面里剥离出来 test。你不需要启动窗口就能验证“子弹向右移动 8 像素后是否撞墙”。这不仅是代码质量的证明，更是答辩时的谈资：你可以说“我用 JUnit 覆盖了核心碰撞逻辑的 12 个用例”。

public class CollisionTest { @Test public void bulletMovingRightShouldHitWallWhenTrajectoryCrossesWall() { // 构造一堵位于子弹移动路径上的墙 Wall wall = new Wall(100, 100, 16, 16); Bullet bullet = new Bullet(80, 108, Direction.RIGHT); bullet.setSpeed(40); // 高速子弹，模拟隧道效应 bullet.move(); // 轨迹矩形应与墙相交 assertTrue(CollisionDetector.hitsWall(bullet.getTrajectory(), wall)); } }

测试里故意把子弹速度设为 40，这种速度下用“当前矩形”检测必然穿墙，但用轨迹矩形能检测到。这个用例的价值在于：它把你修复过的一个 bug 固化成了回归测试，以后不管怎么重构，只要跑一下 JUnit 就知道穿透问题有没有复发。写测试时要注意构造函数的参数顺序：Wall(x, y, width, height)，别把宽高和坐标写反，这种测试代码本身不报错，但断言结果会一直失败，容易被误判成碰撞逻辑有问题。

5.2 日志输出与控制台调试：还原一帧内的事件顺序

游戏的 bug 往往不是出现在代码审查能看出的地方，而是在某个特定的帧序下出现。为了排查，我一般会在关键节点打上带帧号和时间戳的日志，这样能对比“发子弹的帧”和“撞墙的帧”是否连续。控制台调试的时候用System.out.printf是允许的，但正式提交代码前要清理掉高频日志，否则打印 IO 会拖慢帧率。

public void updateGameState() { frameCount++; if (frameCount % 60 == 0) { System.out.printf("[%d] bullets=%d enemies=%d player=(%d,%d)%n", frameCount, bullets.size(), enemies.size(), player.getX(), player.getY()); } // 其他逻辑 }

每 60 帧打印一次的频率不会影响性能，又能让你观察子弹数量和敌人数量的趋势。如果发现bullets数量异常增大，说明子弹没有正确回收。如果发现某个敌人坐标永远不变，说明它的 AI 卡在了边界判断里。日志输出还有一个好处：答辩演示时如果程序当场出问题，你可以切到控制台，从日志里看出是哪一步逻辑断了，这种“当场排错”的表现比任何 PPT 都加分。

5.3 答辩 PPT 这样讲：把亮点放在架构决策与重构过程上

做答辩 PPT 最容易犯的错是把代码逐行贴上去，讲得又长又没重点。老师关心的不是你写了多少行，而是你遇到问题怎么分析、怎么解决。我一般把 PPT 压成四页：第一页讲整体结构和类图，第二页讲你拆解的 2-3 个核心难点，第三页展示核心代码片段和运行效果，第四页放测试结果与后续展望。

这里提一下 java八股文 相关的好处：面试官如果看到你的项目里用了Timer、Runnable、BlockingQueue，很可能顺着问“Timer 和普通 Thread 的区别”“多线程修改集合会有什么问题”。这些恰好是 java 面试题 里高频出现的问题。你在答辩前如果能把项目里用到的线程模型、集合类、Lambda 表达式都解释清楚，就等于把项目复习了一遍知识盲区，比临时背面试题效率高。

答辩演示时要有个“安全演示脚本”：先运行项目展示操作，再打开类图讲结构，最后切到 JUnit 测试结果。不要把 IDEA 里的编译报错留在屏幕上，更不要当着老师的面现场改代码。如果演示新功能时没跑通，就说“这个扩展点我留在后续版本里”，然后立刻切回主流程，保持现场节奏连贯。

6. 进阶一把：把单机版改造成可存档、可调难度的完整作品

如果你的毕设要求更高，或者你想把这套代码放进 java 学习路线 里当第一个完整的“小成品”，我建议再加两个功能：存档系统和难度曲线。存档用Properties最简单，但用 JSON 更现代，你可以手动拼接字符串保存关卡、积分、玩家坐标、剩余生命。关键点是存档写文件必须只发生在主循环线程里，不能一边写一边有 AI 线程修改数据，否则会遇到 java 并发写下的数据一致性问题——典型表现是存档里偶尔出现玩家坐标跑到地图外。

难度曲线可以按关卡动态调整几个数值：敌坦速度、开火间隔、敌坦数量。公式可以写成这样。

public class DifficultyCurve { public static int enemySpeed(int level) { // 基础速度 2，每关加快 0.5，但不超过 6 return Math.min(6, 2 + (int)((level - 1) * 0.5)); } public static int enemyFireInterval(int level) { // 基础开火间隔 2000ms，每关减少 100ms，最低不低于 500ms return Math.max(500, 2000 - (level - 1) * 100); } }

这套曲线本身就是“可玩性”的取舍：前几关节奏慢，后几关需要玩家学会预判。这种参数驱动的设计能引导你在答辩时回答“你如何平衡游戏难度”这种开放问题。Math.min和Math.max的双重约束保证了极端关卡下数值不会被推到不可用范围，这也是工程上写可调参数的一个好习惯。

验证方式我建议做两件事：一是写一个简单的自动测试脚本，模拟玩家按住右方向键 3 秒，断言坦克坐标移动到预期范围且没有穿墙；二是录一段 30 秒的演示视频，观察帧率和行为。视频录制时注意把控制台日志也录进去，这样后期复盘帧率和事件顺序都能对上。我说实话，这种项目做完最大的成就感不是拿到分数，而是发现“原来游戏里的每个诡异现象，最后都能在代码里找到精确到一行甚至一个参数的起因”。这套设计和排错的手感，会在你下一个更大的项目里用很久。希望帮到你。

本文还有配套的精品资源，点击获取