简介：这是一份面向Java初学者的《Java程序设计实验指导书》，适合高校学生或自学入门者配合课程上机实践使用。全书围绕68学时实验安排，涵盖Java基础、Java核心与企业级应用选学三大部分，具体包括运行环境安装配置、基本语法练习、面向对象编程、包/接口/异常处理、数组/向量/字符串、常用系统类使用以及图形界面、多线程等拓展实验，每个实验均配有目的、要求与操作内容，能有效引导读者完成从环境搭建到核心应用的完整训练。压缩包中仅含1个doc文档，体积约530KB，内容包含实验目录、任务时间分配表及详细步骤说明，便于直接打印或按章节查阅。目前已吸引238人学习浏览，适合需要系统梳理Java实验内容、准备上机考核或补充课堂练习的读者下载使用。
1. 一本好的Java实验指导书，为什么值得你先读完再动手
很多同学拿到「java程序设计实验指导书」的第一反应，是翻到最后一个综合实验看热闹，或者对着实验题直接搜现成代码。但如果你不是想应付检查，而是真的打算把Java当成一门能吃饭的手艺，这本指导书其实是别人替你踩过坑之后画出来的训练地图。它能解决的是「顺序不对、什么都学不扎实」的问题：先练什么、后练什么、每个实验要验证哪个知识点，实验指导书都替你规划好了。适合三类人：刚开Java课的学生，想补强动手能力的自学者，以及需要带实验的助教或讲师。把它通读一遍再动手，能省下后面调试的大量时间。
2. 从语法到综合项目：一间Java实验室的五级拆解
2.1 五级拆解：为什么实验顺序比教材目录更讲究
教材通常按「数据类型→运算符→流程控制→数组→面向对象→集合→IO→多线程→网络」的顺序讲，语法上讲得通，但实验如果照搬，你会发现每章都只练了个皮毛。实验指导书的核心价值不在罗列题目，而在编排顺序。我见过效果最好的编排是五级：首先是环境与基础语法，这一级不写业务逻辑，只验证JVM和编译链路；第二级是面向对象，把类、封装、继承落实到一个小型的模拟业务上；第三级是集合与IO，用Map或List管理数据，再用文件持久化；第四级是多线程与网络，做下载模拟或聊天室；最后一级是综合项目，把前四级的技能串起来。
为什么这么排？因为每一级都建立了下一级需要的「默会知识」——比如先理解类的构造器，才能谈集合里存对象；先理解对象序列化，才能谈网络传输。脱离这个顺序直接上综合项目，大概率会被环境问题消耗掉大部分热情。我给A同学调整过实验顺序，他把原本排在最后的「通讯录管理系统」提前到第二周做，结果一周时间都耗在命令行下的环境变量配置和编码转换上。这不怪他，因为第二周他还没建立「包名和目录要一一对应」的直觉。实验指导书把这种陷阱提前规避掉了——它用前几个实验帮你建立环境感，再进入复杂度，这是顺序的价值。
2.2 实验规格怎么写：输入、约束、输出与验收四件套
一个合格的实验单元不应该只有一句话题目，否则学生拿到题目后全靠猜。我在设计实验单元时，会让每个实验包含四个明确的部分：输入描述、约束条件、输出规格和验收方法。输入描述讲清楚程序启动后接受什么——是命令行参数、是用户键盘输入、还是从文件读入；约束条件限定JDK版本、是否允许使用第三方库、数据规模上限；输出规格规定屏幕上应该出现什么格式、文件应该写成什么结构；验收方法告诉学生用什么命令、什么测试用例来证明自己完成了。
下表是一个实验单元的标准骨架：
| 要素 | 说明 | 缺了它会怎样 |
|---|---|---|
| 实验目标 | 一句话说清本次要掌握的知识点 | 容易抄代码，学不到点 |
| 前置知识 | 需要先完成的实验或需自学的概念 | 卡在不懂的名词上 |
| 可复现步骤 | 从新建文件到运行出结果的分步指令 | 不知从何下手 |
| 输入样例 | 一组明确的输入数据 | 边界情况测不到 |
| 输出规格 | 期望的文本格式或文件格式 | 结果对不对全靠猜 |
| 思考题 | 改动某个参数后观察现象 | 无法迁移知识 |
这套规格同样适合自学者：你在给自己定实验任务时，把输出规格写清楚，就等于把验收标准前置了。很多同学问「我这样写对不对」，其实只要指导书里写了输出规格，自己看一眼就能判断，不需要等别人审批。
2.3 以「模拟项目X」为例：一个实验如何串起三章知识点
我常拿一个名称为「模拟项目X」的综合实验来说明指导书的串联技巧。模拟项目X是一个学生成绩管理程序：要求用控制台菜单实现录入、查询、修改、统计，数据要保存到文件，程序启动时自动加载。这个实验横跨了面向对象、集合、IO三个知识板块。用户一进来先选功能（用到流程控制），然后录入学生信息（创建Student对象），多个学生放进ArrayList（集合），保存时遍历集合并写出文件（IO），下次启动再读回集合（IO与集合的配合）。
在这个实验里，每一个步骤都在调用之前实验里练过的能力：比如「修改学生信息」本质上就是先根据学号找到集合下标，再替换对象引用；「统计成绩」就是遍历集合并累加字段。如果学生曾在「集合与IO」实验里单独练过TreeMap排序，到了综合实验就只有组合成本，没有新知识成本。指导书的综合实验不需要新增多少语法，它只是在检验你把已有零件组装起来的熟练度。这也是判断一份指导书好坏的标准：好的综合实验不会突然冒出新API，而是所有考点都在前面出现过。
3. 手把手复现指导书里的三个核心实验：环境、语法与面向对象
3.1 实验一：用命令行验证Java环境，不依赖IDE
很多人习惯打开IDE自动运行，结果Java环境有没有配好、classpath怎么工作，完全黑匣子。所以我坚持让指导书的第一个实验回到命令行。这个实验的目标是确认JDK可用，并理解java与javac的区别。步骤很简单：打开终端，先确认版本，然后手动编译运行一个Hello程序。
# 1. 确认JDK版本和编译器版本 java -version javac -version # 2. 新建一个工作目录，进入目录 mkdir -p ~/java_lab && cd ~/java_lab # 3. 用文本编辑器创建 Hello.java（内容见下方 Java 代码） # 注意：文件名 Hello.java 必须与 public class 名称一致 # 4. 编译：生成 Hello.class 字节码文件 javac Hello.java # 5. 运行：启动JVM加载主类 java Hello这里的参数说明值得单独讲：java命令后面跟的是类名，不是文件名，所以不要写java Hello.class或java Hello.java。javac命令才接收源文件名。另一个关键点是「public class」与文件名的严格一致，大小写也不能错，否则编译直接报错。做完这个实验，你能建立「源码→字节码→JVM运行」三层链路的概念，之后再碰到IDE里「编译能过但运行报主类找不到」，就知道是在哪一层断掉了。
3.2 实验二：学生成绩类——字段、构造器与封装
第二个实验开始进入面向对象。常见指导书会让学生设计一个Student类，包含学号、姓名、成绩，并让类自己负责判断成绩是否合法。设计这个实验的用意是：通过自己写类，理解「私有字段+公开方法」的封装习惯，而不是只把类当结构体用。
// Student.java public class Student { // 私有字段：外部不能直接改，防止把成绩写成负数 private String id; private String name; private double score; // 构造器：对象创建时强制传入三项信息 public Student(String id, String name, double score) { this.id = id; this.name = name; // 在这里调用校验，而不是等外部来检查 setScore(score); } // setter里面有业务规则：成绩必须在0~100区间 public void setScore(double score) { if (score < 0 || score > 100) { throw new IllegalArgumentException("成绩必须在0到100之间，当前值：" + score); } this.score = score; } public double getScore() { return score; } @Override public String toString() { return String.format("%s\t%s\t%.1f", id, name, score); } }代码的逻辑说明：构造器调用setScore而不是直接给字段赋值，是为了让校验逻辑只写一份，所有进入对象的分数都走同一条路径。我在指导书里会特意加一个思考题：如果setScore抛异常，学生成绩列表中已经加入的对象怎么办？让读者意识到异常处理不是课后习题，而是程序运行时真实会遇到的场景。参数说明方面，学号id建议用String而不是int，因为学号容易出现前导零；成绩用double保留小数，但如果平时成绩只记整数，改成int也能接受。真正需要练习的是「把规则放在模型内部」的技巧。
3.3 实验三：集合与文件——通讯录的增删改查
第三个实验通常尝试「集合+IO」，我建议做通讯录而不是学生成绩，因为通讯录的字段是姓名和电话，语义上更接近「键值对」，与Map的匹配度更高。实验要求支持添加联系人、按姓名查找、列出全部联系人，程序退出前把数据写入文件，下次启动自动读取。
import java.io.*; import java.util.*; public class AddressBook { // 用TreeMap存储，key是姓名，value是电话号码 private Map<String, String> contacts = new TreeMap<>(); private File file; public AddressBook(String path) { this.file = new File(path); load(); } // 读取文件：每行格式“姓名,电话” private void load() { if (!file.exists()) return; try (BufferedReader reader = new BufferedReader(new FileReader(file))) { String line; while ((line = reader.readLine()) != null) { String[] parts = line.split(","); if (parts.length == 2) { contacts.put(parts[0].trim(), parts[1].trim()); } } } catch (IOException e) { // 文件损坏时不要让程序崩溃，打印一个提示即可 System.err.println("读取通讯录失败：" + e.getMessage()); } } // 保存到文件：覆盖写，按姓名排序是TreeMap自带的特性 public void save() { try (BufferedWriter writer = new BufferedWriter(new FileWriter(file))) { for (Map.Entry<String, String> entry : contacts.entrySet()) { writer.write(entry.getKey() + "," + entry.getValue()); writer.newLine(); } } catch (IOException e) { System.err.println("保存失败：" + e.getMessage()); } } public void put(String name, String phone) { contacts.put(name, phone); } public String get(String name) { return contacts.get(name); } public static void main(String[] args) { AddressBook book = new AddressBook("contacts.txt"); book.put("张三", "13800000000"); book.put("李四", "13911111111"); System.out.println(book.get("张三")); book.save(); } }参数说明：构造器接收的文件路径是本实验最重要的参数。用相对路径时，程序工作目录取决于在哪里执行java命令，而不是Java代码所在的目录，这是个高频翻车点。建议统一使用完整路径，或者先打印new File(".").getAbsolutePath()确认当前目录。try-with-resources写法（即try后加括号声明资源）能保证reader/writer在代码块结束后自动关闭，避免文件占用。load方法里对IOException做了吞掉处理——这在工具类中是可接受的，但真实项目中应写日志；指导书里特意这么处理是为了说明「异常不一定要向外抛，就地降级也是一种策略」。
提示：上面的三个实验代码只是训练单元，不要当项目模板。真实项目还需要异常处理策略、日志和分层设计。
4. 实验报告的验收标准：从「能跑」到「理解」
4.1 分档评分表：运行结果、代码风格、答辩问题
实验指导书不能只靠「编译通过、运行出结果」来判断完成度，因为抄下来的代码也能编译通过。我见过不少学生代码运行正常，但把局部变量做成类字段、把全部逻辑堆在main方法里，一旦要求加一个小功能就无从下手。所以验收要分三个维度：运行结果是否稳、代码风格是否像工程代码、答辩问题是否答得出为什么。下面是一张实验评分表，可以直接改造成自己的验收模板：
| 维度 | A档（优秀） | B档（及格） | C档（不合格） |
|---|---|---|---|
| 运行结果 | 覆盖常规、边界输入，输出格式与指导书完全一致 | 常规输入通过，边界输入报错或格式略差 | 只有个别输入能跑通，甚至编译都过不了 |
| 代码风格 | 适度拆方法，命名清晰，无重复代码 | 少量方法，字段命名可读 | 全堆在main，类字段滥用 |
| 关键概念 | 能说清每一步为何这样写 | 能描述步骤但说不出原因 | 照着念代码，无法回答改动后果 |
| 实验报告 | 有过程记录、有异常截图、有改进思路 | 有结果截图，缺少过程 | 只有源代码和输出 |
这个表格告诉学生：实验不是「做完就行」，而是「做完并讲清楚」。指导书里可以附一张评分表，让每个学生在提交前自评。自评的过程就是一个「对照标准发现问题」的过程，很多功能上的缺漏在自评阶段就被发现了。
4.2 怎么验证实验真的对了：三组输入检查边界
指导书的每个实验都应该配套至少三组验证输入。第一组是正常输入，比如成绩输入85，程序输出「成绩合格」；第二组是边界输入，比如成绩输入0或100，程序不能崩溃；第三组是非法输入，比如输入-1或「abc」，程序要给出明确提示而不是抛出一堆异常栈。学生可以在实验报告里贴这三种情况的运行截图，这远比一张「运行成功」的截图有说服力。
这里有个技巧：不要手动在控制台慢慢敲测试，写一个临时的测试类，把三组输入提前写成变量，循环调用被测方法。遇到需要人工输入的场景，可以用Scanner从文件读取来模拟。我习惯在指导书里强调：验证实验是否完成，核心不是「程序能跑」，而是「你知道它为什么在这种输入下会这样表现」。这个习惯保持下去，后面学单元测试就是水到渠成的事。
4.3 实验报告写什么：过程记录比截图更重要
实验报告最常见的错误是只贴最终代码和最终截图，看起来像一篇成果展示，而不是学习记录。一份好的报告应该包含「卡在哪、怎么解决」的过程。我在指导书的报告模板里固定设置几个填空位置：第一次运行结果是否符合预期？如果不符合，你怀疑是哪个环节？你尝试了什么修改？结果如何？这些问题强制学生复盘，而不是把代码一贴了事。
更实际的做法是让学生保存命令行终端的完整历史，或IDE的控制台输出，直接粘贴进报告。异常信息本身就是最有价值的报告内容：NoClassDefFoundError、FileNotFoundException、UnsupportedEncodingException都是很好的复盘素材。实验报告的验收标准应该奖励「错误记录」，而非只奖励「一次通过」——因为编译期靠自己排查出来的错误，比顺利运行更能说明对原理的理解。
5. 实验指导书避坑清单：JDK、编码、路径与classpath的5个高频事故
5.1 编译通过但运行报「找不到或无法加载主类」
现象：javac Hello.java没有报错，但执行java Hello时抛出Error: Could not find or load main class Hello。
原因：最常见的有三种。一是java命令后面误加了.class后缀或源文件名；二是当前目录不在classpath搜索范围（现代JDK默认包含当前目录，但要留意环境变量里的CLASSPATH被设成了别处）；三是类不在默认包却在错误的目录下执行。
解决：先去掉后缀，执行java Hello；再检查环境变量里是否有人为设置的CLASSPATH，如果有，把它先清空；最后确认你的类是否声明了package，如果声明了包名，则必须先进入该包对应的父目录，执行java 包名.类名，而不是在源码目录直接运行。这个坑在实验场景中占到一半以上的运行失败，遇到编译过了但运行不起来，优先按这三条排查。
5.2 控制台中文乱码
现象：程序里写了System.out.println("学生姓名");，控制台输出「瀛︾敓濮撶」之类乱码；或从文件读取中文时显示问号。
原因：源码文件的编码和javac编译时用的编码不一致。部分Windows中文环境默认文件编码可能是GBK，而现代JDK的javac默认按UTF-8读取源码，两边对不上就会产生乱码。IDE里正常是因为IDE帮你做了编码转换。
解决：统一编码。最稳的做法是把源码文件全部以UTF-8保存，并在编译时显式声明编码：javac -encoding UTF-8 Hello.java。运行时如果读文件乱码，检查FileReader是否没指定编码。我这里给一个更实际的建议：把编译命令里的-encoding参数写进实验指导书的每个编译步骤里，从第一个实验就建立编码意识。另外，不要靠记事本「另存为」来改编码，因为它可能会加BOM头，给编译带来新问题。
5.3 IDE里能编译运行，命令行却不行
现象：在IDE里点运行按钮一切正常，退出IDE后用命令行javac/java去实验目录执行，却报一堆包找不到。学生经常疑惑：我明明能跑，为什么称为失败？
原因：IDE会自动把依赖的jar包路径和classpath拼好，还会把编译输出目录指向target/classes，你手动执行时没有这些参数，自然找不到类。
解决：命令行实验只依赖JDK自带的工具，不需要第三方库时，命令应该非常简单。如果复杂到需要拼classpath，说明实验还没到使用第三方库的阶段。处理方法是让命令行实验始终工作在「无第三方依赖」的沙盒中，等确实需要加jar包时，再把classpath写进一个run.sh或run.bat脚本里，不要每次都手动复制。IDE能跑不是问题的终点，命令行能跑才是你理解了依赖关系的证明。
5.4 文件写入后内容莫名消失或重复
现象：程序第一次运行保存的通讯录文件还在，第二次运行后文件变成空的，或内容翻倍；也不知道为什么。
原因：FileWriter默认打开文件时直接覆盖内容，而不是追加。如果程序启动时执行load()，退出时执行save()，而save()里使用了覆盖写模式（构造FileWriter时没有传第二个参数为true），上一次的数据就会在加载后又被新对象覆盖为空。内容翻倍则相反——加载时读了一次，保存时又把现有集合和文件旧内容叠加。
解决：明确FileWriter的构造参数：new FileWriter(file)是覆盖，new FileWriter(file, true)是追加。通讯录这种「整体读写」场景应该用覆盖模式，但要保证先把文件内容完整加载到内存再操作，最后整体写回。如果你需要日志追加，才用追加模式。实验指导书最好写清楚每个文件式实验的写入意图，不然学生很难理解文件里最后为什么只剩一行。
5.5 Scanner读取用户输入时，nextInt与nextLine组合出现「怪跳行」
现象：程序先用nextInt()读取了一个数字，再用nextLine()读取字符串，结果字符串那行没有等待输入就直接跳过，输出一个空行。
原因：nextInt()只读取数字本身，不读取数字后面的换行符。换行符留在缓冲区里，随后的nextLine()读到这个残留的换行符，直接返回空字符串，看起来就是「跳过了输入」。这是Java入门实验里最经典的玄学问题之一。
解决：在nextInt()之后额外调用一次nextLine()来消耗掉残留的换行符；或者干脆全部使用nextLine()读取字符串，再用Integer.parseInt()手动转数字。我在指导书里一定会写后一种方案，因为它能避免由「读取方式混淆」引发的一连串意外。这个坑的深层教训是：控制台输入是「字符流」，所有读取方法都在消费同一个缓冲区，理解这一点以后，处理别的混合读取就再也不会靠试错碰运气了。
6. 把指导书升级成自己的训练工具：单元测试与代码审查的进阶姿势
6.1 给每个实验补一条失败测试
指导书里的思考题通常停留在「改个参数跑一遍看看」。但真正让实验价值翻倍的做法，是把「看看」变成「断言」。我强烈建议在学完集合之后，给之前的实验补JUnit测试：给Student类写一个构造器传入负分时是否抛异常的Test，给通讯录写一个重复添加同名联系人时数量不变的Test。这些测试写的不是新功能，而是把实验里你认为「理所当然」的行为用代码固定下来。当你后面重构成绩计算逻辑时，跑一遍全部测试，绿了才敢继续，那种安全感是console输出给不了的。某小组的训练项目能顺利改成用户界面版，靠的就是前三周积累的这些小测试。
6.2 用Git记录每次翻车
另一件我希望更早做的事，是让每个实验从第一天就纳入Git管理。不需要先学分支和远程仓库，只需要在实验目录执行git init，每完成一个小目标commit一次。翻车时git diff能立刻显示出你改了什么代码，这个能力比任何调试器都直接。常见的情况是：有人改排序规则改到一半，程序越跑越乱，靠git stash把工作区退回正确状态，十分钟就恢复进度；没有版本管理的实验只能靠注释代码块一条条试。把指导书作为训练工具，就是要让它成为你练习工程习惯的场地，而不是一门只能背的学科。
从今天起，每次实验都先写一个注定失败的测试，提交一次，再让测试变绿，再提交一次。用这个节奏做完最后一章综合实验，你收获的就不只是语法知识，而是一条完整的「从任务到代码到验证」的流水线。希望帮到你。
本文还有配套的精品资源，点击获取
