企业官网建设流程全解析

做开发的人基本都绕不过这个组合痛点：本地写代码、远程跑服务，结果 DHCP 一换网络，服务器 IP 变了，SSH 工具里的连接配置全部作废，PyCharm 里配置好的远程解释器也跟着失联。更麻烦的是，如果你在 PyCharm 里已经把远程路径、部署映射都配好了，IP 一变，所有路径映射全要重来一遍。这篇文章就围绕 Ubuntu 系统下固定 IP 的完整配置流程，以及 PyCharm 连接远程服务器做开发的全套设置展开，把我实际踩过的坑和验证过的方案完整写出来，适合刚接触 Linux 远程开发的新手，也给已经上手但被网络问题折腾过的同学提供一份排查参考。

1. 为什么需要固定 IP：动态 IP 的隐患与静态 IP 的价值

1.1 DHCP 带来的开发连环问题

绝大多数 Ubuntu 系统在没有手动干预时，默认走的是 DHCP 动态获取 IP。局域网里的路由器会在一个地址池里挑一个空闲地址分配给你，租约到期或者重启设备后，这个地址随时可能变。平时纯当桌面系统用，IP 变了影响不大；但你要是把 Ubuntu 作为远程开发服务器，问题就立刻暴露了。

我在实践中遇到最典型的一个场景：本地 PyCharm 连着远程解释器跑深度学习训练脚本，训练到一半，公司路由器突然重启，服务器 IP 从192.168.1.88变成了192.168.1.126，PyCharm 这边的 SSH Session 直接断开，重新连接需要手动改 Host 地址，同时远程解释器的路径映射也要检查一遍。这种打断不仅浪费时间，还容易让人烦躁——你明明只改了路由器，整个开发环境却跟着遭殃。

更隐蔽的问题在于，很多服务端程序会把自己监听的地址绑定到当前内网 IP 上。比如你用 Flask 启动一个调试服务，代码里写了host='0.0.0.0'还好，但如果哪次不小心写死了某个旧 IP，IP 一变，服务直接起不来，报Cannot assign requested address。排查半天才发现不是代码问题，是 IP 地址环境变了。

1.2 静态 IP 的价值与适用场景

固定 IP 的核心价值就六个字：稳定、可控、可预期。网络环境不变，你的 SSH 连接信息、PyCharm 部署配置、数据库连接串、Nginx 反代设置都可以一劳永逸地写好，不用隔三差五跟着 IP 变动改配置。

固定 IP 最常见的应用场景有三类。第一类是局域网内的开发服务器，比如你有一台装了 Ubuntu 的台式机或旧笔记本，专门用来跑训练任务、构建打包、托管测试数据库，开发机通过内网访问它；第二类是虚拟机里的 Ubuntu 系统，宿主机需要稳定地通过 SSH 连接虚拟机做开发调试，VMware 或其他虚拟化方案下，虚拟机的 IP 如果漂移，NAT 端口映射和 IDE 远程调试配置都会跟着失效；第三类是用做内网测试环境的基础节点，比如团队共用的测试服务器，固定 IP 能保证所有人配置的远程开发环境长期有效。

这里要说清楚一个容易混淆的概念：固定 IP 不等于公网 IP。大部分场景下，我们配置的是内网静态 IP，比如192.168.1.x或10.0.0.x网段，它只在内网可达。如果你的 Ubuntu 是云服务器，本身就有稳定的公网 IP，那这篇文章的固定 IP 配置主要适用于云服务器内部的私有网络接口；如果想通过公网远程访问，那是另外一套安全组、防火墙和认证的话题，不在这篇文章的讨论范围内。

2. Ubuntu 系统固定 IP 配置：方案选型与完整实操

2.1 为什么选 Netplan：从 ifconfig 到 Netplan 的演进

早期 Ubuntu 版本配置 IP 要改/etc/network/interfaces文件，后来 Ubuntu 18.04 开始全面引入 Netplan 作为默认的网络配置管理工具。Netplan 是一个基于 YAML 的声明式网络配置层，它后端可以对接networkd或NetworkManager，你只需要写清楚"我要什么样的网络状态"，Netplan 负责把这份声明翻译成后端能执行的配置。

用 Netplan 配置固定 IP 有几个明显的优势。第一是配置语法统一，整个网络配置收敛到一个 YAML 文件里，可读性和可维护性比ifconfig命令拼凑要强得多；第二是支持原子化应用，netplan apply会把新配置一次性应用到网卡，不需要重启系统，降低配置失误的代价；第三是配置可版本管理，把/etc/netplan/下的 YAML 文件纳入 Git 管理，网络配置出问题可以快速对比和回溯。

我见过不少新手还在用ifconfig eth0 192.168.1.100 netmask 255.255.255.0这种方式配 IP，这种做法的致命问题在于重启网络服务或重启系统后，配置直接丢失，每次开机都要重新设一遍，纯属浪费时间。如果你接触的是 Ubuntu 18.04 以上版本，直接学 Netplan 就够了。

2.2 配置前的准备工作：网卡信息排查与网络规划

动手之前，先用一条命令把网卡信息看清楚。在终端里执行：

ip addr

这条命令会列出所有网络接口。我常用的 Ubuntu 桌面上，有线网卡一般叫eth0、enp0s3、enp3s0这种名字，虚拟机的网卡名常见的是ens33、ens37。你需要记录两样东西：一是你要配置的网卡名称，二是这个网卡当前的 IP 地址和子网掩码。

接着查看当前的路由信息：

ip route

重点关注默认网关，也就是default via后面跟的地址。比如输出default via 192.168.1.1 dev ens33，说明网关是192.168.1.1。网关地址通常就是路由器的 LAN 口地址，这个地址在后续 Netplan 配置里一定要写对，写错的话，即使 IP 配好了，外网也访问不了。

然后再查一下 DNS 配置。Ubuntu 桌面版（特别是用 NetworkManager 管理的版本）默认可以从 DHCP 拿到 DNS；如果你要设置静态 IP，DNS 是要手动指定的，不然配置完固定 IP 之后，域名解析直接失败。

resolvectl status

或者直接看/etc/resolv.conf文件也能大致了解当前 DNS 指向。

关于子网掩码，我建议用 CIDR 表示法，比如/24就等价于255.255.255.0，它表示网络部分占 24 位，可用主机地址是 256 个，实际可用 254 个（去掉网络地址和广播地址）。在 Netplan 配置里直接写192.168.1.100/24，比写netmask 255.255.255.0更简洁，YAML 解析也不会出错。

固定 IP 的挑选有一个原则：不要让固定 IP 落在 DHCP 自动分配的地址池里。假设你的路由器默认地址池是192.168.1.100到192.168.1.200，那你手动指定的 IP 最好在192.168.1.2到192.168.1.99之间，或者干脆用192.168.1.201以上的地址。这样做可以避免 IP 冲突——如果 DHCP 把某个 IP 分配给了另一台设备，而你的服务器也配置了同样的 IP，两台设备就会争抢地址，表现是网络时通时断，极其恶心。

如果你不确定路由器的 DHCP 地址池范围，可以去路由器的管理后台看 DHCP 设置；或者保守一点，选一个明显偏大偏小的地址段。

2.3 Netplan 静态 IP 配置完整实操

确认好网卡名称、网关、DNS 之后，就可以开始配置了。先找到 Netplan 配置文件。不同 Ubuntu 版本的配置文件位置和命名有区别，最常见的几个路径：

• /etc/netplan/00-installer-config.yaml（Ubuntu 20.04 及以上常见的安装器生成配置）
• /etc/netplan/01-netcfg.yaml（部分云镜像或手动安装的场景）
• /etc/netplan/50-cloud-init.yaml（云服务器镜像模板常见）

查看当前生效的是哪个文件：

ls /etc/netplan/

然后编辑这个文件。我习惯用nano，对新手更友好：

sudo nano /etc/netplan/00-installer-config.yaml

以最常见的网卡ens33为例，一个静态 IP 的完整配置如下：

network: version: 2 ethernets: ens33: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 8.8.8.8 - 114.114.114.114

逐行解释一下这份配置的含义。version: 2表示使用 Netplan 的第二个配置格式版本，这是目前所有新版 Ubuntu 通用的，不用动。ethernets下面声明网卡名称，ens33:这个缩进表示对这个网卡的配置块。dhcp4: no是关键中的关键，它关闭了 IPv4 的 DHCP 动态获取，否则即使你写了静态地址，系统开机时还是可能拿 DHCP 分配的结果覆盖静态配置。

addresses列表里填你要指定的固定 IP 和子网掩码，注意用 CIDR 写法。routes配置里，to: default表示默认路由，via后面填网关地址。nameservers下的addresses是 DNS 服务器列表，可以填多个。这里我填的是公共 DNS 和国内常用 DNS 的混合，实际使用中你可以根据自己的网络环境选择，也可以用你公司的内部 DNS。

填完之后先检查配置文件的语法。Netplan 对 YAML 缩进极其敏感，一个空格不对，整个配置文件就解析失败。用命令验证：

sudo netplan generate

只有这条命令没有任何输出，说明配置语法没问题。然后应用配置：

sudo netplan apply

应用完成后，立刻检查网卡和路由：

ip addr show ens33 ip route

正常情况下，你会看到ens33的inet地址变成了192.168.1.100/24，路由表里的default via 192.168.1.1 dev ens33也指向了正确网关。

然后测试内外网连通性。先 ping 网关：

ping -c 4 192.168.1.1

网关通了，说明链路和静态 IP 都没问题。再 ping 一个外网地址：

ping -c 4 8.8.8.8

外网 IP 通了，说明路由转发正常。最后测试 DNS 解析：

ping -c 4 www.example.com

如果域名也能正常解析，说明 DNS 配置成功，整个静态 IP 配置就收工了。

注意：如果netplan apply之后 SSH 连接直接断开，或者终端卡死，大概率是配置有问题。不要慌，重启系统一般能回退到旧配置，或者在物理终端（/虚拟机控制台）上把配置改回来再用netplan generate验证。配置网络的时候，永远不要先关掉你当前唯一的远程连接途径。

2.4 Ubuntu 桌面版与服务器版的配置差异

如果你用的是 Ubuntu 服务器版（Server），上面这套配置直接适用。但如果你用的是 Ubuntu 桌面版（Desktop），情况稍微复杂一点，因为桌面版默认的网络管理后端是 NetworkManager，而不是 systemd-networkd。

刚才的 Netplan 配置里，我们默认走的是networkd后端。桌面版在安装时生成的 Netplan 配置通常长这样：

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

注意这里有个renderer: NetworkManager的字段。如果你要配静态 IP，有两个路径。

第一个路径是在 Netplan 配置里把renderer改成networkd，同时关闭 dhcp4 写上静态地址，然后netplan apply。这样配置后，网卡会从 NetworkManager 的管理中剥离出来，由 systemd-networkd 接管。这种做法的问题是，桌面版的网络管理功能（比如无线网络的切换、连接状态托盘图标位）可能会失效或显示异常。

第二个路径是保留 NetworkManager 作为 renderer，在 Netplan 配置里把静态 IP 写进去。Netplan 会把配置转成 NetworkManager 的键值存储，桌面版也能正常管理。我自己在 Ubuntu 桌面版上的经验是，除非你明确不需要桌面网络管理功能，否则在 Netplan 配置里声明renderer: NetworkManager并设置静态地址，最稳定。但要注意，NetworkManager 对静态 IP 配置的即时生效有时不如systemd-networkd干净，如果netplan apply后没生效，可以试着重启 NetworkManager 服务：

sudo systemctl restart NetworkManager

对于同时安装过桌面版和服务器版组件的系统，配置来源可能交叉，这时候我建议优先检查是否存在/etc/NetworkManager/system-connections/下的连接配置，它可能和 Netplan 抢控制权。最终原则：确保只有一个管理后端在控制网卡，避免双头管理导致的配置漂移。

3. PyCharm 连接远程服务器：部署配置与远程解释器

3.1 PyCharm 远程开发的整体思路

PyCharm 连接远程服务器，本质上是把你的开发环境分成了两个角色：本地 IDE 做编辑、浏览代码、版本管理，远程服务器做实际的解释执行和资源计算。PyCharm 通过 SSH 协议与远程服务器通信，核心有两套机制：一套是 Deployment（部署），负责本地文件和远程文件的同步；另一套是 Remote Interpreter（远程解释器），负责让 IDE 知道远程的 Python 解释器在哪、怎么调用。

这两套机制的关系可以这样理解：Deployment 是"搬运工"，它把本地代码上传到远程、把远程的日志或结果下载到本地；Remote Interpreter 是"执行者"，它通过 SSH 在远程执行 Python 命令。两者必须配合使用才能实现"本地写代码、远程跑逻辑"的效果。

在开始配置之前，你需要确认三件事。

第一，PyCharm 必须是专业版（Professional）。社区版（Community）虽然免费，但只支持本地解释器，远程开发功能被移除了。如果你拿的是社区版，在 Settings 里找不到 Deployment 或 Remote Interpreter 选项，不用怀疑自己不会配，是这个版本根本没有这个功能。

第二，远程 Ubuntu 上要装好 SSH 服务端，并且能从本地访问。检查命令：

sudo apt update sudo apt install openssh-server -y sudo systemctl status ssh

看到Active: active (running)说明 SSH 服务正常。

第三，远程服务器上要有 Python 环境。如果你还没装，先装一个基础版本：

sudo apt install python3 python3-venv -y python3 --version

3.2 配置远程部署（Deployment）

打开 PyCharm，进入 Settings。

在 PyCharm 2023.2+ 版本中，路径是Settings | Build, Execution, Deployment | Deployment。点击加号，选择类型为SFTP，给它起一个形象的名字，比如remote-ubuntu。

然后在 Connection 标签页填写连接信息：

• Host：远程服务器的固定 IP，比如192.168.1.100
• Port：SSH 端口，默认22，如果你改过 sshd 配置，就填你实际用的端口
• User name：登录远程服务器的用户名，比如devuser
• Auth type：选 Password 或者 Key pair。建议用密钥方式，配合 ssh-agent 更安全，但第一次配置为了快速跑通，用密码也行
• Password：填入密码，PyCharm 会帮你保存

填完点Test Connection，这一步就测试了 SSH 连接是否通。如果报错，先检查网络能不能 ping 通目标主机，再检查 SSH 服务是否开启，最后确认防火墙是否放行 22 端口。

Connection 配置通过之后，切到 Mappings 标签页，这里的关键是设置本地路径和远程路径的对应关系。比如你的本地项目在D:\workspace\myproject，远程路径想放在/home/devuser/projects/myproject，那映射就是：

• Local path:D:\workspace\myproject
• Deployment path:/home/devuser/projects/myproject
• Web path: 留空即可，这个是用于 Web 项目预览的，我们做后端开发用不上

这里我强烈建议你在远程路径里建一个专门放项目的目录，不要直接把项目文件散落在用户根目录或/tmp下。原因有二：一是/tmp目录重启会清空，二是根目录下放项目文件在权限管理上非常别扭。建目录命令：

mkdir -p /home/devuser/projects/myproject

Mappings 配置完成后，记得在 Deployment 页面里把你创建的这项设为默认（点一下工具栏上的绿色勾选图标），这样后面的远程解释器配置才能正确识别到关联的部署项。

3.3 配置远程 SSH 解释器

接下来配置 Remote Interpreter。路径在Settings | Project: 你的项目名 | Python Interpreter。

点击设置图标（齿轮），选择Add Interpreter，再选On SSH。这里 PyCharm 会让你选择把远程解释器配置为 SSH 直连方式，或者使用 Docker、WSL 等，我们选 SSH 直连。

然后选择Existing server configuration，如果你之前已经在 PyCharm 里建立过 SSH 连接，这里能直接复用；如果没有，就选New server configuration，把远程 IP、端口、用户名、密码再填一遍。

PyCharm 找到服务器之后，会探测远程 Python 解释器的路径。通常你需要手动指定：

which python3

把输出路径填进去，比如/usr/bin/python3。如果你想用虚拟环境，填/home/devuser/projects/myproject/venv/bin/python这种路径，前提是远程项目目录里已经创建了虚拟环境。

关键一步是设置远程解释器的路径映射。在 Add SSH Interpreter 界面的Python interpreter path和Sync folders区域，PyCharm 会要求你选择远程项目的根路径。这个远程根路径必须和之前 Deployment 里 Mappings 的远程路径保持一致。比如部署映射的是/home/devuser/projects/myproject，这里也要填/home/devuser/projects/myproject。

路径不一致会怎样？PyCharm 会创建一个它自己的临时目录来同步代码，你在本地改的文件传到远程某个乱七八糟的路径下，远程解释器跑的时候根本找不到你的代码模块，报 ModuleNotFoundError。这个坑我踩过不止一次，每次都是因为改了部署映射忘了同步改解释器路径映射。

配置完成后，PyCharm 会自动在远程服务器上检测解释器信息，同时在本地生成一个虚拟环境的影子映射，你在 PyCharm 底部能看到 Python 解释器变成了Remote Python 3.x at 192.168.1.100:22这样的标识。

3.4 远程运行与调试

解释器配置好之后，远程运行就和本地运行一样简单了。先确认文件同步是开的。PyCharm 默认在运行前会执行上传操作，但为了保险起见，你可以在Tools | Deployment | Automatic Upload打开自动上传，这样每次 Ctrl+S 保存文件，本地改动都会自动同步到远程。

运行脚本有两种方式。一种是直接打开本地项目里的main.py，右键选择Run 'main'，PyCharm 会通过 SSH 在远程创建一条执行命令，把本地文件先同步到远程路径，然后在远程解释器里执行。运行结果和调试信息会直接回显在 Python Console 和 Run 窗口里。另一种是在远程终端里手动执行，但既然我们已经在 IDE 里配好了远程解释器，IDE 直接跑是最方便的。

调试的话，在代码行号旁边的空白处点击打上断点，点击 Debug 按钮。PyCharm 通过远程解释器启动一个带 debugger 的 Python 进程，本地 IDE 实时接收远程进程的调试状态。断点命中、单步执行、变量查看这些能力和本地开发完全一致，体验差异很小。

有几个细节值得注意。远程执行时，工作目录默认是同步文件夹的远程路径，如果你代码里有相对路径读文件，要确认远程目录下的文件结构正确。另外，远程环境缺少某些 Python 依赖时，不要急着在本地 pip install，那只是装到你本地；应该通过 PyCharm 的终端（会自动进入远程 SSH 环境）执行 pip 安装，或者在 PyCharm 的 Python Interpreter 设置里查看包列表并安装。

3.5 远程虚拟环境的推荐做法

远程开发里我强烈建议用虚拟环境，而不是直接装在系统级 Python 里。原因很简单：项目依赖隔离开，不同项目用一个 Python 但不同版本包互不影响，而且远程虚拟环境不会污染系统 Python，避免升级系统包时搞坏开发依赖。

在远程项目目录下创建虚拟环境：

cd /home/devuser/projects/myproject python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install flask numpy requests

然后在 PyCharm 的 Python Interpreter 配置里，选择远程解释器时，把解释器路径指定为/home/devuser/projects/myproject/venv/bin/python。这样 PyCharm 运行脚本时自动使用这个虚拟环境，包管理和依赖隔离都清晰。

虚拟环境创建好之后，导出依赖清单也是一个好习惯：

pip freeze > requirements.txt

把这份 requirements.txt 提交到 Git 仓库里，换机器、重建环境时一条pip install -r requirements.txt就能恢复依赖，远程开发的可维护性会明显提升。

4. 常见问题与排查技巧实录

4.1 配置 Netplan 后网络直接不可用/SSH 断开

这类问题的噩梦程度最高，尤其是当你只能通过 SSH 远程操作服务器的情况下。配置netplan apply后 SSH 立刻断开、ping 不通，一般有两种原因：一是配置文件语法错误，二是网络参数（网关、DNS、地址）与当前环境不匹配。

处理办法分优先级。如果你人还在机房或虚拟机的控制台前，直接用sudo nano /etc/netplan/xxx.yaml改回正确的配置，再sudo netplan apply即可。如果只有远程连接，配置错了相当于断了自己后路，所以一定要在配置前留一条备用通道。VMware 虚拟机可以通过 VMware 的控制台直接交互；物理服务器如果有 IPMI 带外管理，也能在断网时进去改配置。

预防措施比事后补救更有效。netplan apply之前，先用sudo netplan generate验证语法；改配置时保留一份旧配置备份：

sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak

如果 apply 之后发现问题，系统重启一般会重新应用上一次成功启动时的配置，也可以试试通过在开机菜单里进入恢复模式来还原。

另外，我见过有人配错子网掩码，把/16写成了/24，导致内网通信范围判断错乱，同网段设备互相找不到。配置完务必检查ip route里路由表是否合理，尤其是默认网关那个default via条目。

4.2 PyCharm 连接远程服务器超时或被拒

PyCharm 报Connection refused或Connection timed out时，按下面顺序排查。

先确认远程服务器的 SSH 服务在跑：

sudo systemctl status ssh

如果显示inactive (dead)，先启动：

sudo systemctl start ssh

再确认端口监听状态：

sudo ss -tlnp | grep 22

输出里有0.0.0.0:22或[::]:22且状态为LISTEN，说明 SSH 服务确实在监听。如果没有输出，大概率是 sshd 没装或者被配置禁用了。

然后是防火墙。Ubuntu 自带的 UFW 如果开启，默认会拦截所有入站连接，除非你放行了 22 端口：

sudo ufw allow 22/tcp sudo ufw status

如果你用的云厂商有安全组，还要在安全组规则里放行 TCP 22 端口。

之后从本地测连接：

ssh devuser@192.168.1.100

如果能直接登录，说明网络和 SSH 都通，问题在 PyCharm 的配置端——回头检查 Host 和端口是不是填对了。如果 SSH 从本地通、PyCharm 不通，很可能是 PyCharm 里保存了旧密码或旧密钥，到 PyCharm 的 Credentials 清理掉重新配置即可。

4.3 路径映射不一致导致的代码找不到问题

PyCharm 远程开发里最隐蔽的问题就是路径映射不一致。症状是：代码能同步、解释器也连上了，但运行时报No such file or directory或ModuleNotFoundError。

检查思路是：Deployment 的 Mappings 里，本地目录对应远程目录是确定的；而 Python Interpreter 配置里的路径，决定了 PyCharm 认为的"项目根目录"。这两个路径必须严格一致。

我举个例子。项目本地在D:\myproject，Deployment 映射里我设置远程部署路径为/home/devuser/projects/myproject下的子目录/src，但 Interpreter 配置里我把同步根目录设成了/home/devuser/projects。这样一来，PyCharm 会认为远程项目根目录是/home/devuser/projects，它同步文件时会把本地/src下的文件传过去，最后文件落在远程目录里结构就对不上，运行时的模块导入路径自然出错。

解决办法：在 Interpreter 配置里把"项目根路径"直接设为和部署映射一致的远程路径。如果项目结构比较复杂，可以把本地路径和远程路径的对应关系进一步细化到子目录，但前提是你在 Deployment 的 Mappings 里做了同样的设置。

4.4 远程文件同步方向搞反或不同步

Automatic Upload 打开后，你每次 Ctrl+S 本地文件都会上传到远程。但有时候 PyCharm 会弹窗提示远程文件较新，问你是否覆盖。这个场景一般发生在远程服务器上有人改了文件，或者你在远程终端里手动编辑过代码。

远程开发的原则是"以本地为准"，本地是你的权威编辑源，远程只是执行环境。如果你在远程手动改了代码，本地的 PyCharm 不会自动感知到，下一次 Ctrl+S 后本地旧文件可能直接覆盖远程新文件。避免这个问题的方法是：任何远程环境里的改动，只做执行验证或临时调试，核心代码修改一律回到本地做。如果真的需要拉取远程新版，用Tools | Deployment | Download from来同步。

还有一个常见的不同步坑：Excluded Paths。如果在 Deployment 的 Excluded Paths 里设置了忽略规则，比如忽略了venv、.git、__pycache__，这些目录自然不会同步。如果发现某个功能文件或配置文件总是不上传，检查一下是不是被误加进了排除列表。我遇到过有人把.env文件排除在外，结果远程环境始终没有配置项，程序启动就报错，查了半天才发现是同步问题。

4.5 远程解释器包环境与本地不一致

远程解释器配置完成后，你在本地 PyCharm 里查看Python Interpreter页面，会看到远程环境的包列表。但要注意：这个列表反映的是远程环境的状态，不是本地的。如果你用本地终端执行pip install xxx，本地包的变动不会影响远程环境。

正确给远程环境装包的方式有三种。第一种是在 PyCharm 的 Python Packages 面板里安装，PyCharm 会通过 SSH 在远程执行 pip 安装；第二种是直接用 PyCharm 内置终端（会自动 SSH 到远程），在远程 shell 里执行 pip install；第三种是先在本地写requirements.txt，上传到远程后执行pip install -r requirements.txt。

我推荐第三种方式，因为它是可记录、可复现的。你可以在项目里维护requirements.txt，把它纳入版本控制。这样不管远程环境坏成什么样，重建一套虚拟环境后用一条命令就能恢复。

远程环境包版本错乱的问题也时有发生。特别是当你把系统 Python 和虚拟环境 Python 搞混时，pip 装的新包可能去了系统环境，虚拟环境里还是旧的。配置远程解释器时，一定在 Interpreter 路径里明确指向虚拟环境的bin/python，并且后续所有 pip 操作都在激活虚拟环境的前提下执行。

写在最后的一些经验

这几套配置反复摸索下来，我最深的体会是：固定 IP 和 PyCharm 远程开发这两件事，单独看都不难，但合在一起最容易出错的地方恰恰是"你以为配好了，其实两边没有对齐"。Netplan 的网络参数要和你实际的局域网环境对齐，PyCharm 的部署映射要和远程目录结构对齐，远程解释器的路径要和虚拟环境路径对齐。每一层对齐失败，都会以各种诡异的现象告诉你：网络不通、文件不同步、模块找不到。

最后分享一个小技巧：每次配置完固定 IP 之后，在 PyCharm 的 Host 位置填 IP 之前，先花十秒钟用本地终端跑一遍ssh user@ip确认能连上，再回头在 PyCharm 里填。这个习惯帮我省下过大量查错时间，因为你永远不知道刚才那步netplan apply到底改成了什么状态。先确认底层网络，再配置上层工具链路，排查效率会完全不同。