企业官网建设流程全解析

简介：这份《Java程序设计实验指导书》面向高校Java课程学习者与授课教师，针对上机实验环节目标不清、练习缺乏体系的问题，提供一套按课时编排的完整实验方案。资源为单个doc文档，压缩包约530KB，内容围绕68学时实验教学展开，涵盖Java运行环境安装配置、基本语法练习、面向对象编程、包与接口及异常处理、数组向量与字符串、常用系统类等基础模块，并延伸至图形用户界面、图形与多媒体处理、流与文件、多线程、网络编程，以及JDBC数据库连接、JSP与Servlet等选学内容。文档按实验目的、实验要求、实验内容分层组织，每个实验均给出明确的知识点与操作任务，便于读者按模块循序渐进地动手编程，理解Java基本结构与程序设计方法，也可作为教师安排实验进度、布置课内任务的参考。目前已有239人学习下载，适合需要系统完成Java上机练习的初学者与教学人员使用。

1. 从一台“干净得过分”的机器说起：Java 实验环境到底要装什么

上周帮一个学弟收拾他新买的笔记本，系统是刚重装的，干净得连解压软件都没有。他打开那份 Java 程序设计实验指导书，翻到实验 1 就卡住了——文档里写的是“SDK 的下载与安装”“设置环境变量”，可他照着网上零散的帖子折腾了一下午，javac一会儿能用一会儿不能用，最后连java -version都开始报错。这种场景我见得太多了：实验指导书本身写得没错，但它默认你懂“装什么版本、装到哪、环境变量为什么这么配”，而这三件事恰恰是新手最容易翻车的地方。

这份指导书覆盖 8 到 12 个实验，从运行环境安装、基本语法、面向对象，一路到包与异常、数组向量字符串、常用系统类、图形界面、多线程与多媒体，再到流与文件、网络编程，选学部分还带 JDBC 和 JSP/Servlet。总上机学时 68，其中实验 1 只占 2 学时，可它决定了后面 66 学时能不能顺利跑起来。所以这篇笔记不按“实验几”来写，而是按“装环境 → 配参数 → 写第一个能编译的类 → 坏了怎么救 → 怎么验证整套实验能跑”的顺序落地，目标很明确：让你在实验 1 就把地基打牢，后面做 Java 实验时不再被环境问题反复打断。

适合谁看：刚拿到这份指导书、准备做第一个 Java 实验的学生；带实验课、需要统一环境的技术人员；以及像我这样，隔一段时间就要在陌生机器上重新配一遍 Java 环境、不想再踩老坑的人。

2. 装 JDK 之前的版本决策：为什么实验指导书里的“SDK”现在要装 JDK

2.1 先搞清楚 SDK、JDK、JRE 这三个词的关系

指导书实验 1 写的是“SDK 的下载与安装”，这个说法有年代感。早期 Java 的开发包确实常被笼统叫 SDK，但现在你打开任何主流发行版，看到的都是 JDK（Java Development Kit）。对做实验的人来说，结论很简单：装 JDK，不要只装 JRE。JRE 只有运行环境，没有javac编译器，而这份指导书里几乎每个实验都要求你“编写、编译、运行”，缺了编译器第一步就断。

JDK 里面已经包含 JRE，所以不需要两个都装。常见做法是只装一个 JDK，把它的bin目录加进PATH，java和javac就都有了。这里有个反直觉的点：很多人以为版本越新越好，但实验指导书里的示例代码带有明显的早期 Java 风格，比如 Applet、Vector、AWT 图形类，这些在新版本里要么被标记废弃，要么行为有变化。所以版本选择不能只看“最新”。

2.2 版本怎么选：LTS 优先，别追最新

我给这套实验环境定的基线是JDK 17（LTS），备选 JDK 11（LTS）。理由不是它新，而是它稳：LTS 版本有长期维护，主流 IDE 和构建工具都完整支持，指导书里绝大多数语法练习、面向对象练习、集合与字符串练习在 17 上都能原样跑通。JDK 8 虽然兼容性最好，但太老，新机器上装完容易和系统里其他工具打架；JDK 21 也能用，但对实验课这种以基础语法为主的场景，没必要承担新版本带来的细微行为差异。

选发行版时，用主流厂商提供的 OpenJDK 构建即可，装完能跑javac就行，不必纠结品牌。真正影响你实验体验的不是发行版，而是下面这几个配置项有没有配对。

2.3 安装路径：别带空格、别带中文

这是血泪经验。Windows 上默认安装路径常常是C:\Program Files\Java\jdk-17，Program Files中间有空格，某些老工具、脚本、甚至指导书里让你手敲的命令行都会在这里出问题。我一般会改成C:\Java\jdk17这种短路径，全英文、无空格。Linux 和 macOS 上同理，装到/opt/java/jdk17或~/java/jdk17，别放在带中文或空格的目录下。

安装本身没什么可讲的，下一步下一步就行，但装完先别急着写代码，先把环境变量配好，否则你会遇到“明明装了却提示找不到命令”的经典问题。

3. 配置环境变量：三个最容易写错的路径和一次验证

3.1 Windows 上的 JAVA_HOME 与 PATH 怎么配

指导书实验 1 的“设置环境变量”这一步，是整套环境里翻车率最高的环节。核心就两个变量：JAVA_HOME指向 JDK 根目录，PATH里引用它的bin。我见过太多人把JAVA_HOME配成bin目录，结果PATH里再拼一次bin，变成...\bin\bin，命令自然找不到。

# Windows 环境变量设置（在“系统属性 -> 环境变量”里操作，等价命令如下） # 1. 新建系统变量 JAVA_HOME，值为 JDK 根目录，不要带 \bin setx JAVA_HOME "C:\Java\jdk17" /M # 2. 编辑 Path，追加 JDK 的 bin 目录（注意是引用 JAVA_HOME，不是重复写死路径） setx PATH "%JAVA_HOME%\bin;%PATH%" /M

逻辑说明：JAVA_HOME是给其他工具（IDE、构建工具、脚本）读的，它们会自己拼\bin；PATH是给命令行读的，必须精确到bin。两个变量各司其职，混用就会出...\bin\bin这种路径。参数上，/M表示写系统级变量，需要管理员权限；如果你只想对当前用户生效，去掉/M即可。改完必须新开一个命令行窗口，旧窗口读的是旧环境，这是很多人“改了没生效”的真正原因。

3.2 Linux 与 macOS 上的写法

Linux 和 macOS 上我一般写进 shell 配置文件，而不是临时export，否则关掉终端就丢。

# 写入 ~/.bashrc 或 ~/.zshrc（macOS 新版默认 zsh） export JAVA_HOME=/opt/java/jdk17 export PATH="$JAVA_HOME/bin:$PATH" # 让配置立即生效 source ~/.bashrc # zsh 用户改成 source ~/.zshrc

逻辑说明：PATH里把 JDK 的bin放在最前面，是为了让系统优先用你装的这个 JDK，而不是系统自带的旧版本。这一点在 Linux 上尤其重要，很多发行版预装了某个 OpenJDK，不调整顺序就会出现“我装的是 17，java -version却显示 11”的玄学现象。改完同样要新开终端或source一次。

3.3 配完立刻验证，别等写代码时才发现

环境变量配好后，先做一次最小验证，三条命令依次跑：

java -version javac -version echo %JAVA_HOME% # Windows；Linux/macOS 用 echo $JAVA_HOME

预期结果是java和javac版本号一致，且JAVA_HOME指向你设定的根目录。如果java有输出而javac提示“不是内部或外部命令”，基本可以断定PATH没配到bin，或者配到了但没开新窗口。如果两个版本号不一致，说明系统里还有另一个 Java 在PATH更前面，需要调整顺序。这一步花两分钟，能省掉后面两小时的排查。

提示：验证时一定用新开的终端窗口。旧窗口的环境变量是启动时快照的，改了什么都不会反映出来，这个坑每年都有人踩。

4. 写出第一个能编译的类：从源文件到运行，把实验 1 走完整

4.1 目录结构和源文件命名规则

指导书实验 1 要求“编写、编译 Java 源程序”，很多人卡在第一步不是不会写代码，而是文件名和类名对不上。Java 的规则很硬：public class的类名必须和文件名完全一致，包括大小写。我建议一开始就养成按实验分目录的习惯，比如~/java-labs/lab01/，每个实验一个文件夹，后面实验多了不会乱。

// 文件名必须是 HelloLab.java，和 public class 名一致 public class HelloLab { public static void main(String[] args) { // 实验 1 的最小验证：能编译、能运行、能输出 System.out.println("Java lab environment is ready."); System.out.println("JAVA_HOME should point to the JDK root."); } }

逻辑说明：main方法是 Java 应用的入口，签名public static void main(String[] args)一个字符都不能改，改了能编译但运行时会提示找不到主方法。System.out.println是最基础的输出，用来确认运行链路通。这段代码不涉及任何指导书之外的依赖，纯粹验证“源文件 → 编译器 → 字节码 → 运行”这条链。

4.2 编译与运行的完整命令

# 进入源文件所在目录 cd ~/java-labs/lab01 # 编译：生成 HelloLab.class 字节码文件 javac HelloLab.java # 运行：注意这里写的是类名，不带 .class 后缀 java HelloLab

逻辑说明：javac负责编译，成功时静默无输出，目录下多出一个HelloLab.class；java负责运行，参数是类名而不是文件名，写成java HelloLab.class是最常见的错误之一。如果编译报“找不到符号”或“类名错误”，先检查文件名大小写；如果运行报“找不到或无法加载主类”，先检查当前目录是否在classpath里，最简单的方式就是在.class所在目录直接运行。

4.3 关于 classpath 的一个务实建议

实验初期，源文件和 class 文件放同一目录，classpath默认就是当前目录，不用额外配。等到实验 4 开始涉及包（package），目录结构会变，那时候再显式指定-cp。我一般会告诉做实验的人：前三个实验不要碰 classpath，默认值足够用，过早引入-cp只会增加变量。等实验 4 创建自定义包时，再按包名对应的目录层级放源文件，用javac -d .让编译器自动生成目录结构，这是后话，但提前知道能少走弯路。

4.4 指导书里提到的 JCreator 要不要装

实验 1 第（六）步提到“安装、使用 JCreator 软件”。这是早期教学常用的轻量 IDE，现在完全可以用更主流的工具替代，但如果你要严格对照指导书截图做实验，装一个也无妨。我的建议是：命令行先跑通，再上 IDE。命令行能跑通说明 JDK 和环境变量没问题，此时任何 IDE 只要指向同一个JAVA_HOME就能用；反过来，如果命令行都不通就上 IDE，出了问题你分不清是环境问题还是 IDE 配置问题，排查成本翻倍。

5. 常见问题排查：五条踩坑记录，每条都对应一个具体现象

5.1 现象：javac不是内部或外部命令

原因：PATH里没有 JDK 的bin，或者JAVA_HOME配成了bin导致路径重复。解决：回看第 3 章，确认JAVA_HOME是根目录、PATH引用的是%JAVA_HOME%\bin，改完开新窗口再试。如果还不行，用where javac（Windows）或which javac（Linux/macOS）看系统实际找到的是哪个路径。

5.2 现象：java -version显示的版本和装的不一致

原因：系统里存在多个 Java，PATH顺序不对，旧版本排在前面。解决：把新 JDK 的bin提到PATH最前面；Linux 上可以用update-alternatives管理，但实验环境里直接调PATH顺序更直接。改完用which java确认指向的是你装的那个。

5.3 现象：编译报“类 HelloLab 是公共的，应在名为 HelloLab.java 的文件中声明”

原因：文件名和public class类名不一致，大小写也算。解决：把文件名改成和类名完全一致。这个错误在实验 2 之后会频繁出现，因为大家开始复制粘贴代码，类名忘了改。

5.4 现象：运行报“找不到或无法加载主类”

原因：运行命令写成了java HelloLab.class，或者当前目录不在 classpath 里，或者类里有package声明但目录结构不对。解决：运行只写类名；确认在.class所在目录执行；如果类声明了包，要在包的根目录用全限定名运行，比如java com.lab.HelloLab。

5.5 现象：中文输出乱码

原因：源文件编码和编译/运行时的默认编码不一致。Windows 中文环境下，命令行默认编码可能是 GBK，而源文件存成了 UTF-8。解决：编译时显式指定编码javac -encoding UTF-8 HelloLab.java，运行时的控制台编码也要对齐。我一般会统一源文件为 UTF-8，并在命令行里带上-encoding UTF-8，避免玄学乱码。

注意：这五条里，前两条属于环境层，后三条属于使用层。排查时先分层，再定位，别一上来就重装 JDK，重装解决不了路径顺序和文件名的问题。

6. 装完怎么验证整套实验环境能跑通：一份可复现的自检清单

环境装完、第一个类跑通，不代表后面 11 个实验都能顺利做。指导书从实验 2 到实验 12 覆盖的语法点跨度很大，我习惯在正式做实验前跑一遍“分层自检”，确认每一层的能力都在。下面这份清单按实验顺序递进，每一条都对应指导书里的一个真实能力点，跑通了再往下做，比做到一半发现环境缺东西要省事得多。

这张表不用一次全跑，但实验 1 到实验 5 这五项建议在开始正式实验前过一遍，因为它们共用同一套 JDK 和 classpath 机制，任何一项失败都说明基础环境有隐患。图形界面和文件流两项，等做到对应实验时再验证即可，它们对环境的额外要求主要是显示环境和文件权限。

具体到操作上，我会用一个最小的“冒烟测试”类把前几项串起来：

// SmokeTest.java：一次验证编译、对象、集合、异常四条链路 import java.util.Vector; public class SmokeTest { static class LabItem { String name; LabItem(String name) { this.name = name; } String describe() { return "lab: " + name; } } public static void main(String[] args) { Vector<LabItem> items = new Vector<>(); items.add(new LabItem("syntax")); items.add(new LabItem("oop")); for (LabItem item : items) { System.out.println(item.describe()); } try { int bad = 1 / 0; // 故意触发异常，验证异常处理链路 } catch (ArithmeticException e) { System.out.println("exception caught: " + e.getMessage()); } } }

逻辑说明：这段代码同时用到了类定义、对象创建、Vector集合、增强 for 循环和 try-catch，正好覆盖实验 2 到实验 5 的核心能力点。编译运行后如果能看到两行lab:输出和一行exception caught: / by zero，说明编译器、运行时、集合类和异常机制都正常。参数上没有任何特殊配置，用的都是 JDK 自带能力，所以它通过就意味着基础环境是干净的。

最后说个我自己的习惯。早些年我图省事，装完 JDK 直接开写，结果做到实验 4 的包和异常时才发现 classpath 一直是错的，前面写的代码全要挪目录，返工了大半天。从那以后，我每次配完 Java 实验环境，都强制先跑一遍上面这个冒烟测试，再对照自检表把前五项过掉，确认无误才动正式实验代码。这套流程看着多花十分钟，实际省下的是后面反复排查环境的时间。希望帮到你。

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