企业官网建设流程全解析

装好Ubuntu 22.04之后，大多数人干的第一件事基本都一样：配网络，换源。但恰恰这两件事，每个环节都有坑等着你。我这几年代人装系统、配服务器，光"上不了网"和"apt update报错"这两个问题就不知道处理了多少次，很多问题其实不是网络本身坏了，而是配置思路不对。

这篇就按我在实验环境里实际操作的顺序来聊，从零开始把Ubuntu 22.04的网络配置和换源整个走一遍，包括为什么这么配、底层原理是什么、遇到异常怎么查。不管你是虚拟机里跑Ubuntu，还是物理机上装双系统，这篇文章的思路都适用。

1. 装完Ubuntu22.04先别急着换源，网络状态才是第一步

很多教程上来就让你改/etc/apt/sources.list，我建议你忍一下。源是要换，但如果你的网络本身就不通，换了源照样报错，而且你还分不清是源的问题还是网络的问题。所以第一步永远是：搞清楚当前系统的网络到底处于什么状态。

1.1 三种网络接入方式的高频翻车现场

Ubuntu 22.04的安装环境大致可分三类，每类的网络翻车点完全不一样。

第一类是物理机直接安装。这种情况网络一般最好办，插上网线或者连上WiFi，桌面右上角网络图标点一点就能连。但翻车的地方在于，桌面的网络管理器和netplan之间可能存在冲突，明明在图形界面里连上了WiFi，终端里却是"Name or service not known"，这时候就要检查是不是NetworkManager和netplan在抢网卡的管辖权。

第二类是VMware或VirtualBox里的虚拟机。这是翻车重灾区。默认NAT模式下，虚拟机可以访问外网，但宿主机访问不了虚拟机；调成桥接模式，宿主机能访问了，虚拟机可能又因为DHCP拿不到IP而彻底断网。很多人配了一晚上，就是在NAT和桥接之间反复横跳。

第三类是WSL2或树莓派这类环境。WSL2默认走NAT网络，配置相对简单，但跨操作系统的网络概念容易让人迷惑；树莓派装Ubuntu Server版则要注意，默认镜像里可能根本没启用WiFi配置，你得提前在SD卡的system-boot分区里写好wpa_supplicant.conf才能连上无线。

1.2 先诊断，再动手：一条命令看清当前网络栈

不管哪种环境，我检查和配置网络的固定顺序如下：

# 1. 查看所有网卡状态和IP地址 ip addr show # 2. 查看当前路由表，确认默认网关 ip route show # 3. 查看DNS解析配置 resolvectl status # 4. 测试是否连通网关 ping -c 4 192.168.x.1 # 5. 测试DNS解析 ping -c 4 baidu.com

第一步是ip addr show，看网卡有没有IP地址。如果网卡下面没有inet字段，说明IP都没拿到，后面什么都别谈，先解决IP问题。第二步是看网关，网关错了IP拿得再准也出不去。第三步看DNS，这一步特别容易被忽略，很多人ping 223.5.5.5能通，但ping baidu.com解析不了，问题就出在DNS上。

插一句，ifconfig这个命令在Ubuntu 22.04里默认已经没有了，需要自己安装net-tools包。我习惯直接用ip命令，输出信息更全，网卡名、MAC地址、IP地址、状态全部一份命令全给你列出来。

Ubuntu 22.04默认的网络配置工具是netplan，它采用YAML格式的配置文件，路径是/etc/netplan/目录下，文件名一般是01-network-manager-all.yaml或00-installer-config.yaml。这个文件内容决定了你的网卡是用DHCP动态获取IP，还是用静态IP。

network: version: 2 ethernets: ens33: dhcp4: true

这个配置表示ens33网卡用DHCP自动获取IPv4地址。如果在VMware里，网卡默认是NAT模式，虚拟机DHCP获取的地址由VMware提供的虚拟DHCP服务器分配，通常是192.168.x.x网段。你在这个阶段需要确认的是：这个YAML文件里网卡名和系统实际网卡名是否一致。很多人直接在教程里复制配置，结果自己网卡叫ens160，配置里写的却是ens33，netplan apply一执行直接报错。

1.3 修改netplan配置的完整流程

如果你的系统里没有现成的网络配置，或者只有NetworkManager的配置，我建议你按下面的方式手动新建一个netplan配置文件。这个流程本身也是个"为什么这样操作"的示范。

# 备份现有配置（如果有） sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak # 编辑配置文件（用vim或nano均可） sudo nano /etc/netplan/00-installer-config.yaml

写入以下内容：

network: version: 2 ethernets: ens33: dhcp4: true dhcp6: false optional: true ens160: dhcp4: true

optional: true的意思是如果引导时该网卡DHCP没完成也不阻塞系统启动，这在笔记本或者多网卡环境里很有用，避免因为某个网卡没拿到IP导致开机等待很久。

改完后执行：

sudo netplan try

netplan try是你最好的朋友。它会在应用新配置前先等120秒，你在这段时间内确认网络正常后按回车确认；如果网络被配坏了，它会等超时后自动回滚到之前配置。我强烈建议不管改什么，先执行netplan try而不是直接netplan apply——这个习惯能救你无数次。

2. 从现象到配置：有线、无线、虚拟机三场景下的网络配置实操

这个部分我按实际使用频率来拆，有线网卡配置、无线网卡连接、虚拟机网络模式选择。每个场景我都会给出现象判断和具体操作。

2.1 有线网卡netplan配置详解

有线和无线在netplan里的配置方式不同。有线用ethernets，无线用wifis。如果你在桌面上用的是NetworkManager，无线网络一般通过图形界面连接，但它也会在netplan配置里显示为一个wifis条目，你需要小心处理。

对于纯有线连接，静态IP配置的netplan文件长这样：

network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 119.29.29.29

解释一下这段配置的意义：

• dhcp4: false：关闭自动获取IP，改用下面手动指定的地址
• addresses：这个网卡的IP地址和子网掩码，/24代表255.255.255.0，这是CIDR表示法，跟你手动填掩码的效果完全一样
• routes to: default via: 192.168.1.1：给这个网卡指定默认网关。default就是0.0.0.0/0，所有不知道怎么走的数据包都从这条路由走
• nameservers：指定DNS服务器，这里我填的是阿里DNS和腾讯DNS，你也可以用114.114.114.114或223.6.6.6

静态IP的好处是稳定，适合服务器或需要远程连接的环境。但坑也在这里：你想配的IP可能和网络里其他设备冲突了，或者网关地址填错——比如你的路由器管理地址是192.168.31.1，你却在配置里写了192.168.1.1，结果就是上不了网。

在实际配置前，先确认你的网段和网关：

# 先临时打开DHCP，拿到地址 # 查看实际分配的IP和网关 ip addr show ip route show

然后照着实际值去填静态配置。

2.2 无线网络：命令行连WiFi的完整姿势

我遇到过不少这样的场景：Ubuntu Server版或者某些桌面版装完后，WiFi图标不见了，图形界面里根本没有网络连接选项。这时候不要慌，Ubuntu 22.04的命令行模式下也可以用nmcli操作NetworkManager连接WiFi。

# 查看无线网卡是否被识别 nmcli device status # 打开无线 nmcli radio wifi on # 扫描可用WiFi nmcli device wifi list # 连接指定的WiFi nmcli device wifi connect "WiFi名称" password "密码"

如果nmcli device status显示无线网卡状态是"unmanaged"，说明这张网卡被netplan接管了，NetworkManager管不了它。解决方法是修改netplan配置，把无线网卡部分写成这样：

network: version: 2 wifis: wlp2s0: dhcp4: true access-points: "你的WiFi名称": password: "你的WiFi密码"

然后sudo netplan apply，系统就会直接用netplan连接WiFi，不需要打开NetworkManager。

与之相反，如果你希望无线网卡由NetworkManager管理（桌面环境更推荐），可以在netplan配置里添加：

network: version: 2 renderer: NetworkManager

renderer: NetworkManager是你用图形界面管理网络的关键。Ubuntu 22.04桌面版默认就是这个，但Server版默认是systemd-networkd。两边别搞混了，renderer选错，图形界面就会出现"设备未托管"的尴尬局面。

2.3 虚拟机里的网络模式：NAT、桥接、仅主机怎么选

VMware和VirtualBox里跑Ubuntu 22.04，网络模式通常有三个选项，很多人选不明白，我直接说结论。

NAT模式：宿主机当路由器，虚拟机通过宿主机转发上网。优点是不需要额外配置，虚拟机只要设置DHCP就能上网。缺点是外部设备无法直接访问虚拟机，适合普通学习和实验场景。

桥接模式：虚拟机直接接入局域网，拥有独立的局域网IP。优点是网络行为跟物理机完全一样，可以被局域网内其他设备访问，适合部署服务、远程SSH连接。缺点是虚拟机IP和宿主机IP容易冲突，且需要局域网里有空闲IP。

仅主机模式：虚拟机和宿主机之间不通，只能宿主机访问虚拟机。适合调试环境，不需要上网。

我个人的建议：如果只是学习，用NAT省心；如果要跑服务让别人访问，用桥接。一旦你从NAT切到桥接，虚拟机IP可能变化，原来SSH配置的旧IP就失效了，这是很多人"切完桥接就连不上"的真正原因——不是网络坏了，是IP变了。

桥接模式下，网卡也必须关闭DHCP或提前设置好静态IP。在VMware里编辑虚拟网络设置，把桥接模式选到正确的物理网卡上，如果宿主机既有有线又有无线，选错了网卡虚拟机一样上不了网。

3. 换源的核心逻辑：apt源配置与仓库优先级

网络通了之后，紧接着就是换源。这一步解决的核心问题是：apt下载软件包太慢。Ubuntu官方源服务器在国外，国内访问速度感人，换到国内镜像源能提速十倍以上。

3.1 为什么换源、源的本质是什么

apt源，本质上是一系列软件包索引文件和.deb安装包的远程仓库地址。你在apt install时，apt会从/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的文件里读取仓库地址，然后从对应的镜像下载索引，再根据索引下载安装包。

Ubuntu 22.04的源配置和旧版本有个重要区别：旧版本把源写在/etc/apt/sources.list一个文件里，新版本把它拆成了.list文件和.sources文件两种格式，位置也可能不同。Ubuntu 22.04默认源文件是/etc/apt/sources.list和/etc/apt/sources.list.d/ubuntu.sources，其中ubuntu.sources是deb822格式，内容是：

Types: deb URIs: http://archive.ubuntu.com/ubuntu/ Suites: jammy jammy-updates jammy-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

这里出现了几个关键词需要理解：

• jammy：Ubuntu 22.04的代号
• main：官方维护的自由软件
• restricted：官方维护的非自由软件（比如一些驱动）
• universe：社区维护的自由软件
• multiverse：有版权或法律限制的软件

换源的逻辑就是把URIs那行从http://archive.ubuntu.com/ubuntu/改成国内镜像地址，其余结构保持原样。

3.2 清华/阿里/中科大源配置文件选择与修改

国内常用镜像源有三个：清华TUNA、阿里云、中科大。我个人最常用清华源，因为同步快、覆盖面广、还有专门的help页面教你配置。

清华源的Ubuntu 22.04配置如下：

deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ jammy-security main restricted universe multiverse

这个配置文件里有四个仓库类别：

• jammy：基础仓库，包含官方发布的稳定包
• jammy-updates：包含更新过的软件包
• jammy-backports：包含从新版本Ubuntu回溯过来的软件包
• jammy-security：包含安全补丁更新

这四个仓库缺一不可。如果你只配了jammy没有jammy-updates，那你安装的软件可能不是最新修复版；如果你少了jammy-security，系统安全更新就收不到了。

阿里云的源长这样：

deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse

阿里云源的地址和清华源的区别只在域名，仓库结构完全一样。中科大的也一样，区别在于域名是mirrors.ustc.edu.cn。

用哪个源取决于你所在地区和网络状况。我测试下来的体感：北方联通网络用阿里云快，教育网或科研机构用清华和中科大快，电信网络三者都差不多。如果你不确定，可以一套源换完试一天，也就多花十分钟时间验证。

3.3 修改源配置的正确顺序与安全更新注意事项

换源的步骤我按从安全到激进的顺序来说：

第一步，备份原有配置：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo cp /etc/apt/sources.list.d/ubuntu.sources /etc/apt/sources.list.d/ubuntu.sources.bak

第二步，修改配置。我这里给一个用sed命令直接替换的通用方法，适用于deb822格式的ubuntu.sources，把archive.ubuntu.com统一替换为mirrors.tuna.tsinghua.edu.cn：

sudo sed -i 's#http://archive.ubuntu.com/ubuntu/#https://mirrors.tuna.tsinghua.edu.cn/ubuntu/#g' /etc/apt/sources.list.d/ubuntu.sources

如果你用的是传统的sources.list格式，也可以直接用编辑器打开把域名换成镜像站地址。

第三步，更新索引：

sudo apt update

这一步会把镜像源里的包索引列表拉到本地。如果中途没有红色报错，说明源配置成功。之后你会发现apt install的下载速度蹭蹭上涨。

关于安全源有必要单独提一点。Ubuntu 22.04的jammy-security这套安全更新源，清华源是直接镜像的。阿里云它的安全更新源同样走http://mirrors.aliyun.com/ubuntu/，不需要额外处理。但如果你用的源商只同步了jammy没有jammy-security，apt update会报404，这时候你需要检查那家镜像站的帮助页面，看看安全源应该用哪个地址。

4. Python生态换源：pip与conda镜像配置

Ubuntu作为Python开发者的主力系统，光换apt源是远远不够的。pip install和conda install的源同样在国外，下载速度慢到怀疑人生。如果你的Ubuntu是拿来跑Python项目的，以下内容直接照抄。

4.1 pip换源的持久化配置

pip的源配置在~/.pip/pip.conf或~/.config/pip/pip.conf文件中，Windows下是在%APPDATA%\pip\pip.ini。Linux下推荐使用~/.pip/pip.conf。

mkdir -p ~/.pip cat > ~/.pip/pip.conf << EOF [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple extra-index-url = https://mirrors.aliyun.com/pypi/simple/ trusted-host = pypi.tuna.tsinghua.edu.cn mirrors.aliyun.com EOF

解释一下这个配置里为什么有两个源：

• index-url：主下载源，所有包都优先从清华PyPI镜像拉取
• extra-index-url：备用下载源，当主源找不到需要的包时，会去阿里云PyPI镜像找

之所以要配备用源，是因为有些偏门的包可能只同步到了一部分镜像站。我遇到过同一个包在清华源有、在阿里源没有的情况，所以配一个备用源确实能减少很多报错。

如果你只是临时下载一个包，也可以用命令行直接指定：

pip install requests -i https://pypi.tuna.tsinghua.edu.cn/simple

但问题是这条命令只对当前这次安装生效，下次装别的包又会打回原形。持久化配置才是正解。

4.2 conda换源：别再死磕.condarc了

conda换源和pip不太一样。conda的源配置在~/.condarc，而且它的镜像配置逻辑比pip复杂一些。

conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ conda config --set show_channel_urls yes

执行完这三条命令后，你的~/.condarc会生成类似这样的内容：

channels: - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/ - https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free/ - defaults show_channel_urls: true

注意最后还有一个defaults。这个默认源必须删掉，否则conda还是会在官方源里找包。

conda config --remove channels defaults

这里有个细节很多人不知道：conda mirror的pkgs/main和pkgs/free已经合并了。新版Anaconda的包都放在pkgs/main里，pkgs/free的包基本不会再有更新，留不留其实影响不大。但如果你在用老版本conda，建议两个都保留。

另外，如果你用的是Miniforge或Mambaforge，那conda源配置完全不同，因为默认走的是conda-forge通道，你需要这样设置：

conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud/conda-forge/ conda config --remove channels conda-forge

4.3 换完源还慢的排查思路

换源后pip或conda下载还是慢，不要直接换另一个源，先分析一下问题出在哪个环节。

用pip装包时加上-v参数可以看到详细的下载地址和耗时。如果显示从pypi.tuna.tsinghua.edu.cn下载但速度还是很慢，可能是你所在网络到这个镜像站的链路问题，这时候换阿里云或中科大的pip源试试。如果下载瞬时速度快但总耗时长，多半是单个包文件下载卡在某个依赖上，可以用--timeout和--retries参数调整。

conda的下载慢还有一个隐蔽原因：conda在安装前需要解析依赖关系，这个"Solving environment"阶段会请求repodata.json文件，如果源服务器上的repodata.json很大（几百MB），即使数据包下载快，解析阶段也会拖很久。这种情况下直接把缓存清掉再试：

conda clean -i -a

-i清索引缓存，-a清所有缓存。清完之后conda会重新拉取repodata，有时候能明显加快安装速度。

5. 换源和网络配置中的高频报错与排查链路

这一节写的是真正值钱的经验。以下每个报错我都实际踩过，且都有一个相对固定的排查思路。遇到问题别慌，对照着一步步查。

5.1 网卡消失： ens33不见了，只有lo回环接口

现象：ip addr只显示lo，没有ens33或eth0。这个现象在VMware里尤其常见，原因通常是虚拟机克隆后网卡MAC地址变化，但系统里旧的网络配置还绑定着旧MAC。

排查链路：

# 查看所有网卡，包括未启用的 ip link show # 查看PCI设备列表里有没有网卡 lspci | grep -i ethernet # 查看内核网络模块是否加载 lsmod | grep -i e1000

在VMware里，网卡型号通常是Intel 82545EM或e1000。如果lsmod里没有e1000模块，说明驱动没加载。

解决方法有两种，一种是用dhclient手动拉起网卡：

sudo dhclient ens33

另一种是检查netplan的配置，把网卡名改成实际存在的名称，然后sudo netplan apply。

如果ip link show里确实看不到网卡，还可以检查一下/etc/udev/rules.d/70-persistent-net.rules这个文件，它记录了网卡和MAC的绑定规则。克隆虚拟机后MAC变了，旧规则会阻止新网卡启动。删除这个文件后重启即可。

5.2 能ping IP但解析不了域名：DNS配置去哪儿了

现象：ping 223.5.5.5通，ping baidu.com报"Temporary failure in name resolution"。

问题几乎都出在DNS配置上。Ubuntu 22.04用的DNS解析工具是systemd-resolved，它会对各网卡配置的DNS进行缓存和转发。

排查链路：

# 查看当前的DNS解析状态 resolvectl status # 查看具体网卡的DNS配置 resolvectl dns # 检查resolv.conf的软链接指向 ls -l /etc/resolv.conf

正常情况下/etc/resolv.conf是一个指向/usr/lib/systemd/resolved.conf的软链接，内容是nameserver 127.0.0.53这样的地址。如果你在netplan配置文件里配了DNS，那resolvectl status显示的DNS应该是你配置的IP。

如果resolvectl status显示网卡没有DNS，可以临时设置：

sudo resolvectl dns ens33 223.5.5.5 sudo resolvectl dns ens33 119.29.29.29

永久生效还是要回到netplan文件里，在对应网卡下加：

nameservers: addresses: - 223.5.5.5 - 119.29.29.29

另一个经典坑是：你往/etc/resolv.conf里手动添加了nameserver，但重启后发现又变回原来的样子。因为systemd-resolved会重写这个文件，你改了也会被覆盖。要么直接用resolvectl命令，要么改netplan，不要去手动编辑/etc/resolv.conf——这是Ubuntu 18.04之后就变了的行为，很多人卡在这里。

5.3 apt update报错：404、Hash Sum mismatch、Temporary failure

apt update报错分三类，表现和处理方式各不相同。

第一种是404 Not Found。这说明源仓库里不存在你请求的路径。常见原因是镜像源没同步某个仓库，或者你的源配置里写了不存在的仓库类别。比如你把jammy-updates写成了jammmy-updates，或者镜像站只同步了jammy而没有jammy-updates。解决方法是去镜像站帮助页面核对一下仓库列表，把不存在的行删掉。

第二种是Hash Sum mismatch。这个报错通常意味着缓存里的索引文件和镜像站的实际文件对不上。多半是之前apt update中途断网，留下了脏缓存。解决方法是清缓存后重新更新：

sudo apt clean sudo rm -rf /var/lib/apt/lists/* sudo apt update

第三种是Temporary failure resolving。这个报错就是DNS解析不了镜像站域名，根源在DNS配置，不是源的问题。先用ping mirrors.tuna.tsinghua.edu.cn测试域名解析，解析失败的回头检查第5.2节里的DNS配置。

5.4 虚拟机克隆后的网络问题与配置重置

如果你在VMware里克隆了Ubuntu 22.04虚拟机，重启后大概率上不了网。原因是克隆后虚拟机的MAC地址变了，但系统里还保留着旧网卡的信息，或者/etc/netplan里的配置还写着旧网卡名。

这是我在用VMware批量创建实验虚拟机时经常遇到的场景。处理方法简单粗暴但有效：

# 删除netplan配置中旧网卡的绑定 sudo rm -f /etc/netplan/00-installer-config.yaml sudo touch /etc/netplan/00-installer-config.yaml # 重新创建一个全新的dhcp配置 sudo tee /etc/netplan/00-installer-config.yaml << EOF network: version: 2 ethernets: ens33: dhcp4: true EOF sudo netplan apply

如果你的网卡不叫ens33，先用ip link show查看实际网卡名，把上面的ens33替换掉。

这个方法比你去逐条排查旧网卡信息快得多。克隆虚拟机嘛，本来就是要一个新环境，直接重置干净的网络配置反而最省事。

6. 配置完成后的验证思路与日常维护建议

配置完网络和源，不代表一劳永逸。我建议你在每次配置完成后都按下面这个顺序做一遍验证，这也算是我自己沉淀下来的一个"验收清单"。

第一步，确认网络连通性：

ip addr show | grep "inet " ping -c 4 223.5.5.5 ping -c 4 baidu.com

第二步，确认DNS解析正常：

nslookup baidu.com

第三步，确认apt源可用：

sudo apt update sudo apt upgrade -s

apt upgrade -s是模拟升级，只展示需要更新的包列表，不实际升级。这一步可以确认源里的包索引没坏。

第四步，验证常用开发工具链：

pip config list conda config --show channels

如果这些输出里显示的源都是你配置的国内镜像，那说明基本完工了。

日常维护上，我分享几个习惯：

更新系统和安装新软件时，先apt update再apt install，不要跳过update直接install，否则容易装到索引里已经下线的旧版本。

apt upgrade之后如果出现"unmet dependencies"错误，用sudo apt --fix-broken install修复，然后重新upgrade。

pip和conda的源配置文件属于用户级配置，同一台机器上不同用户配置可能不同。如果你用sudo pip install，读到的是root用户的配置；普通用户的pip install读到的是当前用户的配置。出现"为什么我配了源还是慢"的问题时，先确认你用的是哪个用户身份装的包。

我一直觉得换源这件事本身没什么难度，难点在于你要理解"源"只是一个地址，换源过程真正做的是"修改apt/pip/conda去哪个地址找软件"。你把这个逻辑想通了，后面的报错排查才会有方向。每次配置完网络和源，我都会习惯性地把每个步骤的命令和输出存一份到笔记里，等下次遇到类似问题，直接对照就能快速定位。这比临时翻教程效率高太多了。