简介：这是一份面向大数据初学者的实验指导文档，聚焦熟悉常用Linux操作与Hadoop操作这一入门实验，适合高校大数据课程、正在自学Hadoop伪分布式搭建或准备完成同类实验任务的人群使用。整包仅一个docx文件，大小约289KB，由作者ADEXOM整理，Word格式便于阅读、编辑和按需截取。已有九百七十四人学习下载。文档先介绍Linux虚拟机安装思路，推荐通过VirtualBox在Windows上安装Ubuntu 16.04或18.04系统，再系统覆盖cd、ls、mkdir、rmdir、cp、mv、rm、cat、tac、more、head、tail、touch、chown、find、tar、grep等常用命令的典型场景，并给出环境变量配置方法；随后进入Hadoop层面，包含Hadoop 3.1.3伪分布式安装、HDFS用户目录创建、文件复制与查看、WordCount实例运行验证等关键步骤。整体既可充当实验前的预习材料，也可在操作时对照查漏补缺，还能为后续大数据实验打下基础。
1. 大数据实验的第一道门槛：先过 Linux 命令这关，再碰 Hadoop
这份实验资源解决的是很多初学者卡在起跑线上的问题：想学 Hadoop，结果被 Linux 虚拟机安装、环境变量、伪分布式配置这些前置条件劝退。实验内容不复杂，却把「能跑通」和「跑不起来」之间的所有环节都过了一遍——从 VirtualBox 装 Ubuntu，到十几个高频 Linux 命令的逐个练习，再到 Hadoop 3.1.3 的单机伪分布式部署和 WordCount 验证。我拆完这个实验资源后最大的感受是：Hadoop 本身并不难，难的是你心里清楚每一步在做什么。这篇笔记把整个流程按实战顺序拆开，命令、参数、配置文件、踩坑记录都写在对应位置，新手可以照着敲，熟手可以直接跳到第 5 章看那些真正让你翻车的细节。
2. 文件与目录操作：从 cd 到 tar，把高频命令一次练熟
2.1 目录切换与查看：cd、ls 的肌肉记忆
实验第一部分是对 Linux 基础命令的密集训练，目的是让手指记住这些命令，而不是查一次用一次。先看最常用的目录切换和查看：
cd /usr/local # 绝对路径切换，进入 /usr/local 目录 cd .. # 回到上一级目录，注意 .. 和 . 的区别 cd ~ # 回到当前登录用户的主文件夹，root 用户就是 /root ls -l /usr # 长格式列出 /usr 下的所有文件和目录逻辑说明：cd不带参数直接回车也会回到主文件夹，和cd ~等价；ls -l比裸ls多输出权限、所有者、大小、修改时间，后面的实验步骤里几乎都要靠这些信息来判断文件状态。参数说明：ls常用组合是-la，a用于显示隐藏文件，因为实验里反复操作的.bashrc就是隐藏文件，不加a根本看不到。
这里有个新手容易忽略的点：cd ..和cd ../..的区别。前者回到上一级，后者回上两级。在/usr/local目录下执行cd ../..会直接落到根目录/，如果你后续要操作的是/usr下的其他目录，路径就会算错。我一般会让学生养成先pwd再操作的习惯，pwd这条命令实验里虽然没有单独列出来，但排查路径问题的时候是第一利器。
2.2 新建与删除：mkdir 的 -p 参数和 rmdir 的局限
实验要求练习嵌套目录的创建和删除，这是最容易暴露理解偏差的地方：
mkdir /tmp/a # 在 /tmp 下创建单层目录 a mkdir -p /tmp/a1/a2/a3/a4 # -p 参数允许一次性创建多级嵌套目录 rmdir /tmp/a # 删除空目录 a，目录非空会报错 rm -rf /tmp/a1 # 递归强制删除 a1 整棵目录树逻辑说明：mkdir -p是实验里明确要求掌握的参数，它的作用是在目标父目录不存在时自动逐级创建，不加-p遇到/tmp/a1/a2中a1不存在的情况会直接报错。rmdir只能删空目录，实验里要删a1/a2/a3/a4这种嵌套结构时，必须先删最内层再逐级往外删，非常麻烦。参数说明：rm -rf中r表示递归，f表示强制，这是删除非空目录的实际手段。注意rm -rf没有任何后悔药，敲之前一定确认路径，我见过有人把/tmp写成/后缀少敲一个字符，整台虚拟机直接报废。
这里还要区分rmdir和rm -r：前者是专门为删除空目录设计的，后者是通用删除。实验特意把两种删除都安排上，本质是让你理解「目录非空时为什么 rmdir 会翻车」。我一般会提醒初学者，看到rmdir报错Directory not empty不用慌，换成rm -rf即可，但删除前用ls看一眼目录内容是好习惯。
2.3 复制、移动与删除：cp、mv、rm 的权限边界
接下来是文件操作的核心三件套，实验场景是主文件夹下的.bashrc和新建的 test 目录：
cp ~/.bashrc /usr/bashrc1 # 复制 .bashrc 到 /usr 并重命名 mkdir /tmp/test && cp -r /tmp/test /usr/ # 复制目录必须加 -r，否则报错 mv /usr/bashrc1 /usr/test/bashrc1 # 移动文件到 test 目录下 mv /usr/test /usr/test2 # 重命名目录 rm /usr/test2/bashrc1 # 删除单个文件 rm -r /usr/test2 # 删除整个目录逻辑说明：cp复制目录时如果不加-r，会报omitting directory的错，这是实验里最典型的报错之一。mv是移动和重命名共用一条命令，目标路径存在就移动，目标路径不存在且以原名字结尾就是重命名。参数说明：cp -r的r和rm -r语义一致，都是递归；mv不需要递归参数，目录整体搬移是它的默认行为。
这块有个容易被忽略的细节：不同用户之间的文件操作涉及权限。比如~/.bashrc属于当前登录用户，但/usr目录的写权限可能只属于root。如果实验用的是普通用户身份，执行cp ~/.bashrc /usr/bashrc1可能会因为/usr目录没有写权限而失败，解决办法是先su root切换身份，或者用sudo前缀执行。我在帮学生排查时发现，很多人卡在这里不是命令敲错，而是用户权限不够，报错信息里通常带着Permission denied，看到这几个单词第一反应是切 root。
2.4 压缩、查找与检索：tar、find、grep 的组合用法
实验在命令练习的尾部安排了tar打包、find查找和grep字符串搜索，这三个命令是后面处理 Hadoop 日志和配置文件时最常用的：
mkdir /test && tar -zcvf /test.tar.gz /test # 打包并压缩 tar -zxvf /test.tar.gz -C /tmp # 解压到 /tmp 目录 find ~ -name ".bashrc" # 从主文件夹查找指定文件 grep "examples" ~/.bashrc # 在文件中搜索字符串逻辑说明：tar -zcvf四个参数分别是z（gzip 压缩）、c（创建归档）、v（显示过程）、f（指定文件名），f后面必须紧跟归档文件名。解压时-C指定解压目标目录，不加就解压到当前目录。参数说明：find ~ -name ".bashrc"中~是搜索起点，-name后面跟文件名模式，区分大小写；grep默认输出匹配行的完整内容，-n参数可以显示行号，排查配置文件时比不带行号直观得多。
这三个命令在后续 Hadoop 操作里的使用频率很高。比如 Hadoop 日志文件动不动几百兆，tar用来归档旧日志；find用来定位core-site.xml、hdfs-site.xml的绝对路径；grep用来在 XML 文件里快速找fs.defaultFS或dfs.namenode.name.dir的配置值。实验把这几个命令放在 Linux 基础部分，实际上是在为后面的 Hadoop 操作铺路。
3. 文本查看与环境变量：cat 到 vim 的排查基本功
3.1 正向、反向与分页查看：cat、tac、more 的适用场景
实验要求对.bashrc做多种方式的查看，这个文件是 Linux 用户环境配置的核心，后面配置 Java 环境变量也要改它。先看查看类命令：
cat ~/.bashrc # 一次性输出全部内容 tac ~/.bashrc # 从最后一行开始反向输出 more ~/.bashrc # 分页显示，空格翻页，q 退出逻辑说明：cat适合文件内容较短、一次性看完的情况；tac是cat的反向拼写，行为也是反向输出，实际使用频率不高，但实验要求掌握它的存在；more适合长文件分页查看，翻页到末尾自动退出。参数说明：more查看过程中按/可以搜索关键词，按q退出，按b回翻一页，这些交互命令在排查 Hadoop 日志时很实用。
实际排查中more的体验并不算好，看完内容想回翻很别扭。我一般会建议直接上less，它支持上下方向键自由翻页，搜索高亮也更清晰。实验里没提less，但你把more练熟之后，less的命令交互基本是同一套逻辑，属于一次学会两个工具的情况。
3.2 只看头尾：head 和 tail 的截取思路
查看文件的头尾是日志分析的日常工作，实验安排了四个组合场景：
head -n 20 ~/.bashrc # 查看前 20 行 head -n -50 ~/.bashrc # 查看除最后 50 行以外的全部内容 tail -n 20 ~/.bashrc # 查看最后 20 行 tail -n +50 ~/.bashrc # 查看从第 50 行开始到末尾的内容逻辑说明：head -n 20和tail -n 20是对称的，一个取前一个取后。关键差异在head -n -50和tail -n +50上：head的负数参数表示「排除末尾多少行」，tail的正数参数表示「从第几行开始」，两个命令的参数含义正好互补。参数说明：tail -f是另一个高频用法，f表示持续跟踪文件末尾新增内容，排查 Hadoop 启动日志时，开着tail -f再触发一次启动，能看到实时输出。
这套头尾查看思路在 Hadoop 运维里几乎是每天都会用到的。Datanode 启动失败时，先tail -n 100看日志末尾的异常堆栈；日志被写满时，head -n -200把旧内容截出来；tail -f挂着观察 NameNode 格式化过程中的实时状态。实验把head和tail放在 Linux 基础训练里，用意就是后续不专门教日志排查工具，直接拿这两个命令顶上去。
3.3 时间戳与所有者：touch 和 chown 的权限操作
实验里有两个容易被忽略但实际很重要的命令，touch和chown：
touch /tmp/hello # 创建空文件或刷新已有文件的时间戳 touch -d "5 days ago" /tmp/hello # 把文件时间戳修改为 5 天前 chown root:root /tmp/hello # 修改文件所有者和所属组 ls -l /tmp/hello # 查看修改后的文件属性和时间逻辑说明：touch有两层用法，文件不存在时创建空文件，文件存在时更新访问时间和修改时间。-d参数可以直接指定一个日期字符串，实验里的"5 days ago"是相对时间的写法。chown语法是chown 用户名:组名 文件路径，修改后ls -l输出里的第一列会从原来的hadoop hadoop变成root root。参数说明：chown通常需要 root 权限，普通用户改自己文件的所有者会报Operation not permitted，实验环境下如果落在这个错上，加sudo或切 root 执行。
这块和 Hadoop 的关联在于，Hadoop 的 HDFS 目录权限和 Linux 文件权限是两套体系，但 HDFS 默认会映射 Linux 用户信息。chown练不熟，后面调整 HDFS 文件所有者时还得回来翻命令。我一般会让学员实际操作一次chown后再改回来，把两个方向的命令都敲一遍，记忆会更牢。
3.4 环境变量配置：vim 编辑 ~/.bashrc 的完整路径
实验要求在~/.bashrc里配置 Java 环境变量，这是整个 Linux 命令训练通往 Hadoop 安装的桥梁。完整流程如下：
vim ~/.bashrc # 打开用户环境配置文件 # 在文件末尾追加以下内容： export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PATH=$PATH:$JAVA_HOME/bin export HADOOP_HOME=/usr/local/hadoop export PATH=$PATH:$HADOOP_HOME/bin source ~/.bashrc # 重新加载配置，立即生效 echo $JAVA_HOME # 验证环境变量是否写入成功逻辑说明：vim打开文件后按i进入插入模式，编辑完按Esc退出插入模式，输入:wq保存并退出。source命令的作用是让当前 shell 重新读取配置文件，不开新终端也能生效。echo $JAVA_HOME如果输出路径，说明配置成功；如果输出空行，说明变量名拼写有误或没有加载。参数说明：export PATH=$PATH:$JAVA_HOME/bin这种写法是在原有PATH基础上追加新路径，冒号是路径分隔符，漏掉$PATH会导致系统命令都找不到。
这里有个版本匹配问题值得注意。Hadoop 3.1.3 对 Java 版本有硬性要求，Java 8 是官方推荐的版本，Java 11 也能跑但会有警告输出。实验资源里虽然只写了配置 Java 环境变量，没指定具体版本，但根据 Hadoop 3.1.3 的官方支持范围，Java 8 最稳妥。检查 Java 是否已安装用java -version，没装的话先apt install openjdk-8-jdk，再回来配环境变量，顺序反了容易白配。
4. Hadoop 伪分布式安装：从解压到 WordCount 跑通的完整路径
4.1 前置条件与版本选择：JDK、SSH、下载源
Hadoop 伪分布式安装的前置条件比想象中多，实验资源默认你已经有 Ubuntu 虚拟机，但实际动手前还需要确认三件事：
java -version # 确认 JDK 版本，1.8 最佳 ssh localhost # 确认 SSH 服务可用并已配置免密登录 # 如果免密未配置，执行以下步骤： ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys逻辑说明：ssh-keygen生成 RSA 密钥对，-P ""表示空密码，-f指定密钥文件路径。生成的公钥追加到authorized_keys后，ssh localhost就不再需要输入密码，Hadoop 的各个守护进程之间靠 SSH 通信，这一步不配好后面会连环报错。参数说明：chmod 600把公钥文件权限收紧到仅所有者读写，权限过宽会导致 SSH 拒绝使用该密钥。
JDK 和 SSH 都确认没问题后，再下载 Hadoop 安装包。实验资源指定的是hadoop-3.1.3.tar.gz，下载后解压到/usr/local/hadoop：
sudo tar -zxvf hadoop-3.1.3.tar.gz -C /usr/local sudo mv /usr/local/hadoop-3.1.3 /usr/local/hadoop sudo chown -R $USER:$USER /usr/local/hadoop逻辑说明：解压后目录名带版本号，mv重命名为hadoop后，后续配置路径可以少写一串版本字符。chown -R把整个 Hadoop 目录的所有者改为当前用户，这一步很关键——Hadoop 在运行过程中会在安装目录下写临时文件，如果目录属于 root，普通用户的 hadoop 身份去启动守护进程时会遇到权限问题。我一般建议专门创建一个hadoop用户来运行伪分布式集群，和实验资源里「使用 hadoop 用户登录 Linux 系统」的要求正好对上。
4.2 配置文件修改：core-site.xml 与 hdfs-site.xml 的参数
Hadoop 伪分布式的核心配置在两个 XML 文件里，位于/usr/local/hadoop/etc/hadoop/目录下。常见做法是先配置core-site.xml指定 NameNode 地址，再配置hdfs-site.xml指定数据块副本数和 NameNode 数据目录：
<!-- core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/opt/module/hadoop-3.1.3/data</value> </property> </configuration><!-- hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/module/hadoop-3.1.3/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/module/hadoop-3.1.3/data/datanode</value> </property> </configuration>逻辑说明：fs.defaultFS指定文件系统的访问入口，伪分布式下指向localhost:9000。dfs.replication副本数必须设置为 1，因为伪分布式只有一台节点，默认 3 个副本会导致 DataNode 启动时报错找不到足够的存储位置。hadoop.tmp.dir的作用是定义 Hadoop 运行时数据的根目录，实验资源里core-site.xml指定的缓存数据路径就在这个配置项里，第 5 章的那个经典踩坑案例就是从这个目录下手解决的。
配置 HDFS 相关参数时，dfs.namenode.name.dir和dfs.datanode.data.dir可以单独指定，它们决定 NameNode 的元数据和 DataNode 数据块的落地位置。如果这两个配置不写，Hadoop 会默认落到系统临时目录，重启后数据可能丢失。实验资源里没有单独强调这两个参数，但排查 Datanode 启动失败时，data目录就是战场。
4.3 启动验证：start-dfs.sh 与 jps 的结果解读
配置文件就绪后，首次启动前必须先格式化 NameNode：
hdfs namenode -format格式化成功后，会输出successfully formatted字样。然后启动 HDFS 守护进程：
start-dfs.sh jps逻辑说明：jps是 JDK 自带的 Java 进程查看工具，输出里逐个列出当前运行的 Java 进程。一个正常的伪分布式集群，jps应该能看到 5 个进程：NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager。如果只看到 4 个或更少，缺失的进程名就是排查的起点。
参数说明：start-dfs.sh实际启动的是 NameNode、DataNode 和 SecondaryNameNode 三个进程；ResourceManager和NodeManager属于 YARN 组件，需要单独执行start-yarn.sh启动。实验要求的 WordCount 运行不依赖 YARN，用 MapReduce 的本地模式也能跑，所以jps里只要看到 NameNode 和 DataNode 都在，核心部分就算通过了。
4.4 WordCount 运行验证：确认伪分布式真的能跑
实验要求运行 Hadoop 自带的 WordCount 实例来验证集群状态。完整流程是先本地创建样例文件，上传到 HDFS，再调用 WordCount 执行统计，最后查看结果：
mkdir -p ~/wordcount_input echo "hello hadoop hello world" > ~/wordcount_input/file1.txt echo "hadoop bigdata linux hadoop" > ~/wordcount_input/file2.txt hdfs dfs -mkdir -p /user/hadoop/input hdfs dfs -put ~/wordcount_input/* /user/hadoop/input/ hadoop jar /usr/local/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.1.3.jar \ wordcount /user/hadoop/input /user/hadoop/output hdfs dfs -cat /user/hadoop/output/part-r-00000逻辑说明：前两条命令创建本地输入文件并写入测试内容，第三条和第四条把文件上传到 HDFS 指定目录。hadoop jar调用的是 Hadoop 自带的示例 JAR 包，wordcount是其中的一个可执行类，输入路径和输出路径都必须是 HDFS 上的路径。输出路径不能预先存在，否则运行会报错，这是 WordCount 的一个使用限制。最后一条命令查看统计结果，正常输出会按单词分组并计数。
这里给出 WordCount 的进阶用法：如果本地模式下不想走 HDFS，可以在mapred-site.xml里配置mapreduce.framework.name为local，然后直接传本地文件路径运行。但实验的核心目的是验证伪分布式集群，所以按 HDFS 路径跑一遍是必要的。
5. 避坑排查：Datanode 起不来、Live Nodes 为 0 的典型现场
5.1 Datanode 无法启动：Cluster-Id 不一致的完整复盘
现象：启动 HDFS 后执行jps，NameNode 和 SecondaryNameNode 都在，但 Datanode 进程始终不出现。访问 NameNode 的 Web 界面9870端口，Live Nodes数量显示为 0。查看 Datanode 日志，报错信息中包含类似Cluster ID mismatch或Incompatible clusterIDs的关键字。
原因：这是伪分布式安装里最典型的翻车现场。安装过程中反复执行了多次hadoop namenode -format，每次格式化都会生成一个新的clusterID，写在 NameNode 的元数据目录current/VERSION文件里。Datanode 首次启动时会读取datanode目录中保存的clusterID，如果它记录的 ID 和 NameNode 当前使用的 ID 不一致，就会拒绝注册并退出。格式化次数越多，两个 ID 错位的概率越大。
解决：核心思路是让 NameNode 和 DataNode 使用同一个clusterID，最彻底的办法是把上次格式化留下的数据全部清掉，从零开始。具体操作如下：
# 1. 找到 core-site.xml 中 hadoop.tmp.dir 指定的路径 grep "hadoop.tmp.dir" /usr/local/hadoop/etc/hadoop/core-site.xml # 结果通常是 /opt/module/hadoop-3.1.3/data # 2. 删除整个数据目录 rm -rf /opt/module/hadoop-3.1.3/data # 3. 重新格式化 NameNode hdfs namenode -format # 4. 重启 HDFS stop-all.sh start-all.sh # 5. 验证进程和节点状态 jps逻辑说明：删除数据目录会把 NameNode 的元数据和 Datanode 的数据块索引全部清空，相当于抹掉以往所有格式化的痕迹。重新格式化后生成的clusterID就是全新的，Datanode 首次启动时会把新 ID 写入自己的数据目录，两边就能对齐了。参数说明：stop-all.sh和start-all.sh是 HDFS 和 YARN 的联合启停脚本，比单独执行start-dfs.sh和start-yarn.sh更省事。注意第 5 步的jps结果如果出现 5 个进程，才算真正恢复。
5.2 Live Nodes 为 0 的排查顺序
现象：9870端口能打开，但 Web 界面显示Live Nodes为 0。jps里 Datanode 的进程在，只是网页上注册不了。
原因：能打开9870说明 NameNode 存活，但 Datanode 进程存在不等于它成功注册到 NameNode。注册失败的最常见原因是clusterID不一致或网络端口被防火墙拦截。
解决：按顺序排查，从进程、日志、端口、配置文件四层推进：
jps # 第 1 层：确认 5 个进程都在 tail -n 100 /usr/local/hadoop/logs/hadoop-hadoop-datanode-*.log # 第 2 层：日志是最直接的证据 ss -tlnp | grep -E "9870|9000|9864" # 第 3 层：确认端口是不是真的在监听 cat /usr/local/hadoop/data/current/VERSION # 第 4 层：检查 clusterID 是否一致逻辑说明：日志文件会明确写出 Datanode 注册失败的原因，常见的三种是clusterID不匹配、dfs.datanode.data.dir目录权限不足、dfs.namenode.http-address配置指向了错误的端口。ss -tlnp用于确认 NameNode 的9000端口和 Datanode 通信端口9864是否处于监听状态。VERSION 文件里的clusterID需要和 NameNode 侧的数据目录中记录的比对，不一致就回到 5.1 的重置思路。
5.3 SSH 免密失败导致启动中断
现象：start-dfs.sh执行过程中反复提示输入密码，或直接报错Permission denied (publickey)，集群启动流程被中断。
原因：Hadoop 守护进程之间通过 SSH 协议通信，如果当前用户没有配置到本机的免密登录，脚本在尝试连接localhost时就会卡在认证环节。实验环境如果是新装的 Ubuntu，SSH 服务可能默认未安装。
解决：先确认 SSH 服务已安装并启动，再配置免密：
sudo apt install openssh-server service ssh status ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost # 验证免密是否生效参数说明：ssh-keygen的-P ""是空密码参数，不加这个参数会交互式询问两次密码，脚本化执行容易被卡住。测试免密是否生效的标准动作是ssh localhost后直接返回提示符，而不是出现密码输入界面。
5.4 9870 端口打不开与防火墙问题
现象：NameNode 启动正常，jps显示进程存活，但在宿主机浏览器里访问虚拟机 IP 的9870端口一直转圈或拒绝连接。
原因：Ubuntu 默认防火墙ufw可能没有放行9870端口，或者虚拟机的网络模式设置导致宿主机无法直接访问。VirtualBox 默认的 NAT 模式下，宿主机访问虚拟机需要端口转发，容易漏配。
解决：优先切换网络模式为桥接，然后放行端口：
sudo ufw allow 9870/tcp sudo ufw status # 如果输出显示 status: active，说明放行规则已生效逻辑说明：桥接模式下虚拟机直接获取局域网 IP，宿主机可以像访问普通设备一样访问虚拟机的 9870 端口，省去 NAT 端口转发的配置。如果不想切桥接，也可以在 VirtualBox 的网络设置里添加一条端口转发规则，把宿主机的 9870 转发到虚拟机的 9870。我一般建议直接桥接，伪分布式实验的网络需求不高，桥接最省心。
6. HDFS 常用操作的验证清单：一条命令链确认集群没白装
实验的最后一部分是 HDFS 的常用操作，包括创建用户目录、新建文件夹、上传本地文件、复制回本地。这四步操作串起来就是一条完整的验证链路，适合全部跑完后用来做最终检查：
# 1. 建立 HDFS 用户目录 hdfs dfs -mkdir -p /user/hadoop # 2. 在用户目录下创建 test 文件夹 hdfs dfs -mkdir /user/hadoop/test # 3. 把本地 .bashrc 上传到 HDFS test 目录 hdfs dfs -put ~/.bashrc /user/hadoop/test/ # 4. 查看 test 目录内容确认上传成功 hdfs dfs -ls /user/hadoop/test # 5. 把 HDFS 上的文件复制回本地 hdfs dfs -get /user/hadoop/test/.bashrc /usr/local/hadoop/这套命令链里最值得留意的是-put和-get的方向。很多人第一次用时容易把路径顺序搞反，-put是本地在前 HDFS 在后，-get是 HDFS 在前本地在后。另外，-get复制回来的文件名如果和本地的.bashrc重名，会直接覆盖，实验资源里特意提到复制到/usr/local/hadoop目录下，就是为了避免和主文件夹的原文件冲突。
一个进阶验证技巧是加-du和-stat查看 HDFS 文件的实际大小和副本状态：
hdfs dfs -du -h /user/hadoop/test hdfs dfs -stat "%b %o" /user/hadoop/test/.bashrc参数说明：-du -h输出文件大小，h参数以人类可读格式显示；-stat "%b %o"中的%b是文件大小，%o是副本数，伪分布式下副本数应为 1。执行完这条还能看到元数据状态，可以作为集群健康度的一个辅助证明。
这个实验资源整体走下来，我从拆解到复现花了大半天时间。最大的教训就是格式化 NameNode 前一定要想清楚后果——我中途有一次就是多敲了一次hadoop namenode -format，把clusterID打乱，Datanode 直接罢工，最后不得不删掉整个 data 目录重新来过。从那以后我每次在伪分布式环境里做格式化，都会提前确认一下core-site.xml里的hadoop.tmp.dir路径，再顺手执行一遍jps和ss -tlnp，把进程和端口状态固定下来再动手。这套检查习惯虽然多花两分钟，但省掉的排查时间远不止这些。希望这篇笔记能帮你在踩坑之前就把这一步跨过去。
本文还有配套的精品资源，点击获取
