企业官网建设流程全解析

用 VS Code Remote-SSH 连上树莓派，在 Ubuntu 22.04 环境里直接把树莓派当成主力开发机来写代码、跑调试、开终端、映射端口，这套玩法我今年在好几个项目里都用得很顺手。以前给树莓派做开发，要么蹲在显示器前操作，要么用 Vim 在终端里硬扛，远程改代码同步麻烦，调试更是一言难尽。用了 Remote-SSH 之后，本地的 VS Code 界面、快捷键、插件全都作用于远程设备，体验上几乎和开发本机项目没区别。这篇东西我尽量把从烧录系统、换源、配 SSH、装扩展，到离线安装 VS Code Server 的完整过程都写出来，适合准备用树莓派做毕业设计、边缘计算实验，或者单纯想把吃灰的树莓派 4B 重新用起来的同学。

Remote-SSH 不是简单的“远程看代码”，它把 VS Code 的客户端/服务端架构拆开了：本地跑界面，远端跑语言服务、调试器、终端，两边通过 SSH 通道通信。这意味着你在本地装的界面插件（主题、快捷键、代码片段）能用，而 Python、C/C++ 这类依赖语言服务的插件实际在树莓派上运行，代码索引、补全走的是树莓派的 CPU。这个机制对树莓派这种小型设备尤其重要，因为它决定了哪些插件放本地、哪些放远端，也决定了第一次连接时为什么要在远端下载并启动 VS Code Server。

1. 为什么我建议用 Remote-SSH 开发树莓派

1.1 传统开发方式的痛点

我在接触 Remote-SSH 之前，给树莓派写代码基本是两条路线。第一条是把显示器、键盘、鼠标全接上，把树莓派当成一台小电脑直接用。本地跑 VS Code 看起来没毛病，问题是树莓派 4B 的 CPU 性能有限，Ubuntu 22.04 桌面版本身就要吃掉不少内存，再开个 VS Code，内存经常飙到 80% 以上，编译项目的时候风扇呼呼转，打字都能感觉到卡顿。第二条路线是用 SSH 登录到树莓派里用 Vim、nano 写代码，虽然省资源，但代码补全、跳转、调试这些现代编辑器体验全没了，改个多文件项目得来回切换，效率很低。

很多人卡在中间状态：用 VS Code 编辑本地文件，再通过 SFTP 插件同步到树莓派。这种思路的问题是双向同步很容易冲突，你改了本地文件忘了上传，或者树莓派上程序自己生成的日志、配置文件被误同步覆盖，排查起来非常痛苦。还有一类需求是开发串口、GPIO 设备控制程序，本地文件同步过去之后还得手动 SSH 去启动、看日志，来回折腾很消耗耐心。

1.2 Remote-SSH 的工作机制

Remote-SSH 改变了这个模式。它的核心思想是：VS Code 安装一份“客户端”在本地，负责界面渲染和处理你的操作；同时在远程机器上启动一个“服务端”，负责实际的文件读写、代码分析、终端执行。本地和远程之间通过 SSH 协议互相通信，你需要做的只是在本地安装 Remote-SSH 扩展，然后告诉它你要连哪台机器。

连接成功后，你可以像操作本地项目一样操作树莓派上的文件：左侧资源管理器显示的是远程目录，打开的文件内容实时从远端读取，Ctrl+S 保存时直接写回树莓派。最妙的是 VS Code 的终端窗口，打开后默认就是登录到树莓派的 shell，你可以直接跑python3 app.py，或者systemctl status查服务状态。调试功能同样走远程，断点、变量监视、调用栈全都在本地界面上展示，但实际运行的是树莓派里的程序，这对开发 GPIO 控制、传感器读取这类单板程序太有价值了。

要理解插件为什么分“本地”和“远程”两类。Remote-SSH 连接成功后，VS Code 界面左下角会显示一个绿色的“SSH: 主机名”标记。你在扩展面板里会看到有些插件是装在本地的，比如汉化包、主题、Remote-SSH 本身；有些插件则会自动安装到远程端，比如 Python、Pylance、C/C++ 这些。因为语言服务需要在有解释器、编译器的那一端运行，远程插件直接跑在树莓派上，这样它才能找到/usr/bin/python3，才能用树莓派上的编译链。

1.3 树莓派 + Ubuntu 22.04 的选型逻辑

树莓派的可选操作系统很多，官方自己的 Raspberry Pi OS（基于 Debian）也流行，我为什么用 Ubuntu 22.04 LTS？最直接的原因是开发环境的一致性。我平时的主力服务器、云主机很多都是 Ubuntu 22.04，树莓派也用同一套系统，那么apt包管理、systemd 服务管理、Python 环境、Docker 容器在树莓派和服务器上表现一致，写好的东西可以直接迁移部署。Ubuntu 22.04 是 2024 年仍然在标准支持期内的 LTS 版本，软件源里的 Python 3.10、GCC、Node.js 版本都比较新，对做毕业设计、跑现代框架来说更省心。

另一个原因是树莓派 4B 的性能正好够 Ubuntu 桌面版跑起来，但我强烈建议装 Ubuntu Server 版本，或者桌面版装好后把桌面关掉，只保留命令行。原因很简单：我们用 Remote-SSH 开发，树莓派本身根本不需要桌面环境，多跑一个桌面就多消耗几百兆内存。我在 4GB 内存的树莓派 4B 上，把桌面服务禁用后，空闲内存能空出来 2.5GB 以上，留给编译和容器使用，体验提升非常明显。

2. 环境准备：烧录系统、换源、开启 SSH

2.1 烧录 Ubuntu 22.04 LTS

树莓派 4B 烧录 Ubuntu，我还是推荐用官方 Raspberry Pi Imager。这个工具支持直接下载系统镜像并写入 SD 卡，省去手动下载镜像、解压、写卡的多步操作。在 Imager 的"Choose OS"里选择 "Other general-purpose OS" -> "Ubuntu" -> "Ubuntu Server 22.04 LTS (64-bit)"，注意选 64 位版本，因为树莓派 4B 的 CPU 是 64 位架构，而且现在很多 Python 包、Docker 镜像只有 arm64 版本，32 位系统会遇到兼容性问题。

烧录前有个容易被忽略的操作：点击右下角的齿轮图标，进入高级设置，提前配置好 hostname、用户名和密码，最关键的是勾选“Enable SSH”，用密码认证。这样 SD 卡烧好后，系统第一次启动就能直接 SSH 登录，不用插显示器去手动配置。如果你已经烧好了系统才发现没开 SSH，也有补救办法：把 SD 卡重新插到电脑上，在 boot 分区里创建一个名为ssh的空文件，同时编辑network-config文件配置好网络（如果是有线连接基本不用管），再把卡插回树莓派启动，SSH 服务就会自动开启。

SD 卡的选择上，我建议用至少 32GB 的 Class 10 / A1 以上速度的卡。树莓派 4B 的 SD 卡读写速度往往成为系统瓶颈，Remote-SSH 使用中如果感觉打开文件卡顿、终端输出迟钝，换个高速卡比任何软件优化都有效。我给树莓派跑 Docker 和编译任务时用的是一张 128GB 的 A2 卡，整体体验比原来那张杂牌卡好很多。

2.2 登录系统后第一时间要做的换源

Ubuntu 22.04 装好后，默认的 apt 软件源指向的是官方服务器。如果你在国内网络环境，执行apt update时经常速度很慢，我实测过官方源在部分网络下每秒只有几十 KB，甚至直接卡住。所以登录系统后的第一件事就是换源，这步做完，后面安装任何软件包都会顺畅很多。

换源操作其实不复杂，核心是把/etc/apt/sources.list里的官方地址替换成国内镜像源。Ubuntu 22.04 的源格式是新式结构，文件内容大概长这样：

# 先备份原文件 sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # 查看系统版本代号，22.04 对应 jammy lsb_release -c # 编辑源列表 sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list sudo sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list

这里我用阿里云镜像源做演示，你完全可以根据自己网络环境选择清华 tuna、中科大 USTC 或者其他镜像站，地址格式都一样。替换完成后执行：

sudo apt update sudo apt full-upgrade -y

apt update是刷新软件包索引，full-upgrade会把系统现有的软件包升级到软件源里的最新版本。刚烧录的系统做一次全量升级非常有必要，里面包含了很多安全补丁和 bug 修复，而且后续装新软件时避免依赖版本不一致的问题。

有个细节提醒：如果你用的是 Ubuntu 桌面包，换源时还要同步处理内置软件商店（Snap Store）的更新源，不过我们这次主推 Server 版加 Remote-SSH 开发，Snap 的问题基本可以忽略。另外/etc/apt/sources.list.d/目录下可能有第三方源文件（比如 Docker 官方源），它们不归sources.list管，需要单独处理。

2.3 开启并测试 SSH 服务

Ubuntu Server 默认安装了 OpenSSH Server，但如果没有在 Imager 里提前开 SSH，系统起来后服务可能没启动。我先说怎么确认状态：

# 查看 SSH 服务状态，active (running) 表示正常运行 systemctl status ssh # 如果没运行，先启动并设置开机自启 sudo systemctl enable --now ssh

确认服务在运行后，先在树莓派本机（或者通过本地终端登录）查一下 IP 地址：

ip addr show

找到eth0（有线）或wlan0（无线）对应的 IP，比如192.168.1.100。然后在你的电脑上用任意 SSH 客户端测试：

ssh username@192.168.1.100

第一次连接会提示确认远程主机指纹，输入yes，再输入密码就能登录。能通过这个命令登录进去，说明 Remote-SSH 的基础已经通了。关于用密钥替代密码，我在 3.2 节专门讲，这里先不展开。

一个建议是给树莓派设置静态 IP，或者至少在路由器上做 IP 绑定。树莓派默认通过 DHCP 获取地址，重启后 IP 可能会变，到时候 Remote-SSH 的配置文件里地址不对，就会连接失败。我是在路由器后台根据树莓派网卡的 MAC 地址绑定了一个固定 IP，这样不管重启路由器还是树莓派，地址都不会变，省了很多麻烦。

3. 本机 VS Code 与 Remote-SSH 连接配置

3.1 安装 VS Code 和 Remote-SSH 扩展

本地电脑上，VS Code 直接去官网下载安装包就行，这一步不再赘述。装好后打开 VS Code，左侧扩展面板搜索Remote-SSH，认准发行方是 Microsoft 的那个（扩展 ID 是ms-vscode-remote.remote-ssh），点击安装。这里我建议顺手把另外两个官方远程扩展也装上：Remote-SSH: Editing Configuration Files和Remote Explorer，前一个让你在 VS Code 里直接编辑 SSH 配置文件时有语法高亮和补全，后一个在侧边栏提供远程主机管理视图，方便多主机切换。

安装完扩展后，VS Code 会在最底部状态栏的左侧显示一个绿色的远程标记区域，打开命令面板（Ctrl+Shift+P），输入Remote-SSH: Connect to Host，就能看到它要求你输入 SSH 连接命令或者选择配置文件里的主机。第一次连接时它会尝试在远程主机上安装匹配版本的 VS Code Server，这个过程是自动的，只要网络通畅就能完成。

这里要提一个影响后续体验的关键点：VS Code Server 的版本必须和本地 VS Code 版本严格匹配。Remote-SSH 每次连接都会检查版本，发现不一致会提示重新下载。如果远程端曾经安装过旧版本，可能需要手动清理~/.vscode-server目录才能解决版本冲突问题。这个我在第 5 章的问题排查里细说。

3.2 配置 SSH Config：从口令到密钥

用命令面板输入完整 SSH 命令能连，但每次都敲太麻烦。我建议把主机信息写进~/.ssh/config文件，Remote-SSH 会自动读取这个文件，连接时只要选主机名就行。在本地终端执行：

code ~/.ssh/config

如果文件不存在，VS Code 会提示创建。一个典型的树莓派配置长这样：

Host rpi4j HostName 192.168.1.100 User ubuntu Port 22 ServerAliveInterval 30 ServerAliveCountMax 3 ForwardAgent yes

我解释一下每个字段的作用。Host是你在 VS Code 里看到的别名，随便起；HostName是实际 IP 地址；User是登录用户名；Port默认是 22，如果改过 SSH 端口就填实际的；ServerAliveInterval和ServerAliveCountMax是心跳参数，防止网络环境不稳定时连接被中间设备静默断开。实际使用中我发现这个设置对长时间保持 Remote-SSH 会话特别重要，不加的话，笔记本合盖再打开后远程连接经常假死。

用密码登录虽然简单，但每次连接都要输入密码，而且有些场景（比如 VS Code 打开后自动重连）密码认证不够顺滑。更好的方式是配置 SSH 密钥认证。在本地生成密钥对：

# 如果已经有 ~/.ssh/id_ed25519 可以跳过生成步骤 ssh-keygen -t ed25519 -C "raspberry-pi-ubuntu" # 将公钥复制到树莓派，会自动追加到远程 ~/.ssh/authorized_keys ssh-copy-id ubuntu@192.168.1.100

之后再次 SSH 连接就不再需要密码。ssh-keygen生成密钥时建议给私钥设置一个 passphrase，虽然每次使用可能要输入一次，但私钥泄露时的风险会小很多。我个人是配合系统钥匙串来管理 passphrase，平时使用几乎无感。

3.3 连接远程并安装远程插件

配置写好后，VS Code 左下角点击绿色远程按钮，或者命令面板执行Remote-SSH: Connect to Host，选择rpi4j。如果密钥认证配置成功，你甚至看不到任何密码输入提示，十几秒内新窗口就打开了。

新窗口打开后第一件事是到扩展面板检查远程插件。你会发现扩展列表被分成了“本地 - 已安装”和“SSH: rpi4j - 已安装”两类。你需要把开发树莓派项目真正用到的插件装到远程端。方法很简单：在扩展面板搜索插件，点击安装时 VS Code 会自动判断并安装到当前连接的远程环境。常见的远程插件组合：

• Python：包含 Pylance、Python Debugger，是树莓派 Python 开发的核心。
• C/C++：由微软官方维护，支持 IntelliSense、调试和编译任务。
• Docker：管理树莓派上的 Docker 容器和镜像。
• Remote-SSH 本身不需要装到远程，它只是本地扩展。

有些同学误以为所有插件都要装远程，其实不对。像中文语言包、Material Theme 这类纯界面插件，装在本地就好，远程端装了反而浪费空间。判断标准很简单：插件是不是需要读取远程的文件、调用远程的解释器/编译器？需要就装远程，否则就用本地。登录远程终端后执行code --install-extension ms-python.python这类命令也可以安装远程插件，但多数情况下直接点击界面安装就够了。

4. 深度开发实战：把树莓派当主力开发机

4.1 远程文件夹、终端和端口转发

连接稳定后，日常开发操作和本地几乎无差别。你通过File -> Open Folder打开的是树莓派上的目录，VS Code 会在远程端为这个目录建立一个工作区，文件监视、Git 操作、终端路径都绑定到这个目录。我在树莓派上专门建了~/projects目录放所有代码，VS Code 记住工作区后，每次重连自动恢复到上次打开的目录，省时省力。

端口转发是 Remote-SSH 非常实用的功能。树莓派上跑的 Web 服务、Jupyter Notebook、Flask 应用都是监听在树莓派的某个端口上，在本地浏览器直接访问192.168.1.100:5000也能打开，但想用localhost:5000访问，就得靠端口转发。打开命令面板执行Remote-SSH: Forward Port from Host，输入远程端口号（比如5000），VS Code 会自动将远端的 5000 端口映射到本地的随机端口，并在右下角弹窗告诉你本地访问地址。你也可以在“端口”面板里手动指定本地端口，比如映射成localhost:8501，这样访问本地地址就和访问远程服务对齐了。

我经常用端口转发调试树莓派上的 FastAPI 服务。本地写好接口代码，保存后远程端uvicorn热重载，然后本地浏览器直接访问localhost:8000/docs看 Swagger 文档，整个调试闭环非常顺畅。还有一个冷门用法是把 SSH 本身的转发能力扩展为动态转发，但这需要手动编辑 SSH 配置，日常开发用不到，这里就不展开了。

4.2 Python 虚拟环境 + Docker 部署

在树莓派上做 Python 开发，我强烈建议所有项目都使用虚拟环境，别把依赖直接装到系统 Python 里。树莓派的系统 Python 被很多系统工具依赖，你贸然升级某个包，可能把系统环境搞坏。我在树莓派上的标准做法是：

sudo apt install -y python3-venv python3-pip mkdir -p ~/projects/car-detection && cd ~/projects/car-detection python3 -m venv venv source venv/bin/activate pip install --upgrade pip

创建虚拟环境后，VS Code 会自动检测到.venv或者你手动创建的venv目录，并把 Python 解释器自动指向虚拟环境。你在 VS Code 里新建终端时，终端也会自动激活虚拟环境（前提是 VS Code 选择的 Python 解释器是虚拟环境里的）。之后运行pip install安装的包都会装进虚拟环境，不会污染系统 Python。如果在 VS Code 右下角看到 Python 解释器还是系统的，手动按 Ctrl+Shift+P 执行Python: Select Interpreter切换一下。

如果是做毕业设计，数据采集、模型推理这类任务经常需要固定的运行环境，直接用 Docker 是更省心的方案。Ubuntu 22.04 上安装 Docker 官方源和引擎：

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker.gpg echo "deb [arch=arm64 signed-by=/usr/share/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu jammy stable" | sudo tee /etc/apt/sources.list.d/docker.list sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 将当前用户加入 docker 组，免去每次执行 sudo docker sudo usermod -aG docker $USER

树莓派是 arm64 架构，Docker 镜像必须选 arm64 或者多架构版本。比如跑容器化的 Python 应用，用python:3.10-slim官方镜像就支持 arm64。Docker 安装完，你完全可以在树莓派上跑一套完整的服务端环境，再用 Remote-SSH 把容器内的开发调试都串起来。

4.3 串口、GPIO 与外设开发

树莓派开发有很大一部分涉及硬件，比如用 GPIO 控制舵机、读取传感器、操作串口。Remote-SSH 也没落下这个场景。你在树莓派上用 Python 的 GPIO 库（RPi.GPIO、gpiozero 或树莓派 5 上新的 gpiod 接口）写代码，VS Code 的代码补全和语法检查都能正常工作，因为 Python 插件运行在远程端，读得到树莓派上的 GPIO 库。

串口开发有一点特别：程序运行后，串口数据流在树莓派和外部设备之间传输，VS Code 的终端里只能看到日志输出。我的习惯是让程序把串口收发数据同时打到日志里，通过 Remote-SSH 终端实时观察。另外要注意的是串口权限，Ubuntu 22.04 下串口设备一般位于/dev/ttyUSB0或/dev/ttyAMA0，当前用户必须加入dialout组才能访问：

sudo usermod -aG dialout $USER

改完用户组后要重新登录生效。以前我在树莓派上调试一个 GPS 模块时，程序一直报Permission denied: /dev/ttyUSB0，排查半天发现就是用户组权限没到位。这类硬件权限问题在树莓派开发里非常常见，加完之后基本一劳永逸。

如果你用的是树莓派 Pico 这类单片机的开发板，VS Code 也有对应的方式。Pico 本身不算运行 Ubuntu 的主机，它通常通过 USB 连接树莓派，树莓派上安装picotool和pico-sdk，通过 Remote-SSH 在树莓派上交叉编译并在终端里烧录。搭配 Wokwi（一个 VS Code 模拟器扩展）可以在没有硬件的情况下仿真 Arduino、树莓派 Pico 的电路，对调试逻辑很有帮助。

4.4 离线安装 VS Code Server

Remote-SSH 第一次连接时，会在远程主机上下载并安装 VS Code Server。这个下载过程如果卡住，最常见的表现是 VS Code 显示“Unable to download VS Code Server”或者 "Failed to fetch" 一类的错误，下面跟着一个很长的commit id链接。我之前在腾讯云轻量服务器上也遇到一模一样的问题，当时网络环境下载官方服务器文件特别不稳定，反复重试都可能失败。

这个 commit id 是有用的。VS Code 每次发布版本，Server 的下载地址都会被改写成：https://update.code.visualstudio.com/commit:<commit_id>/server-linux-arm64/stable。你可以先在本地浏览器把对应的server-linux-arm64包下载下来（这里之所以要留一个 commit id，就是为了手动定位版本），然后通过 scp 传送到树莓派上：

# 在错误信息里找到 commit id 和下载链接 # 在本地下载好 server-linux-arm64 文件，比如 vscode-server-linux-arm64.tar.gz scp vscode-server-linux-arm64.tar.gz ubuntu@192.168.1.100:/tmp/

然后在树莓派上按 VS Code Server 的目录规范放置：

mkdir -p ~/.vscode-server/bin/<commit_id> tar -xzf /tmp/vscode-server-linux-arm64.tar.gz -C ~/.vscode-server/bin/<commit_id> --strip-components=1

解压完成后，在 VS Code 里重新执行Remote-SSH: Kill VS Code Server on Host（如果有这个命令），或者直接断开当前连接并重新连接。这一回连接时 VS Code 会发现远端已经存在对应版本，不再触发下载，直接启动服务。整个过程完全绕开了远程下载这一步，只依赖你本地网络能下载到 Server 包。

关于这个问题的根源，我自己总结原因就是本地访问 VS Code 官方 update 服务器不稳定，不一定是你电脑的问题。手动离线安装是原理最清晰、最可控的解法。如果你嫌手动不方便，也可以尝试在树莓派上配置镜像源或使用内网穿透服务，但说到底最稳的还是离线放文件，一次放完，后面连接都不会再触发下载。

5. 常见问题与排查实录

5.1 问题速查表

项目用多了以后，Remote-SSH 的坑基本都踩过，我挑一些最高频的整理成表格，方便你直接对照排查：

说几个容易混淆的地方。第一，ssh-copy-id虽然方便，但它默认只复制~/.ssh/id_rsa.pub或id_ed25519.pub，如果你用了非默认文件名，需要加-i参数指定公钥文件。第二，VS Code Server 的缓存目录~/.vscode-server如果损坏，最直接的解决办法就是把它整个删掉，让 VS Code 重新安装，别在这上面花太多时间修复。第三，如果你发现某个插件在远程端装不上，可以试着重启 VS Code 窗口，很多时候是插件市场的远程会话同步没走完。

5.2 三条避坑经验

第一条经验是给树莓派做好散热。树莓派 4B 在高负载下（尤其是你用 Remote-SSH 跑编译、跑模型推理）发热非常猛，不加散热片和风扇的话，CPU 会主动降频，表现出来就是 Remote-SSH 界面响应变慢、编译时间突然拉长。我之前用铝合金外壳加双风扇套件，效果显著，树莓派 4B 的 CPU 温度基本能压在 60°C 以下。做毕设长跑实验的同学，这一步别省。

第二条经验是养成定期快照或备份的习惯。SD 卡出错、系统崩溃、误删文件这些事在树莓派上不比服务器少见。我的做法是：所有代码和配置用 Git 管理，代码推送到远程仓库（比如 Gitea 自建或公有 Git 平台），系统层面的关键配置用脚本固化。这样就算 SD 卡整个挂掉，重烧系统后跑一遍脚本就能恢复大部分环境，不至于从零开始。

第三条经验是善用 Remote-SSH 的“再次连接”能力。VS Code 每次启动时会尝试恢复到上次的远程工作区，但在网络切换后这项工作偶尔会失败。我在笔记本电脑上专门养成了一个习惯：如果打开 VS Code 后处于“无连接”状态，先等两三秒让自动重连尝试，如果没反应，就手动用命令面板重新连接。看似是个小动作，但能避免很多“我已经连上了，怎么操作没反应”的假象。

最后分享一个小技巧：Remote-SSH 支持把本地的settings.json同步到远程，但更推荐的做法是为树莓派项目单独建.vscode/settings.json放在项目目录下，比如把 Python 解释器路径、代码格式化配置、终端自动激活虚拟环境等写进去。这样项目在任何机器上打开都能保持一致的开发配置，远程协作或换电脑后不需要重新调环境，对团队项目或者隔几个月再回来看代码的“考古”场景特别友好。

说实话，Remote-SSH 用顺手之后，树莓派就变成了一台真正的开发服务器。我甚至把路由器的端口映射打开，在公司也能连回家里树莓派上继续调试，配合端口转发功能，远程开发的体验非常接近本地。你如果正在为树莓派开发环境的搭建头疼，照着我这套流程走下来，基本不会再被环境问题打断思路，可以把精力放回功能本身。