之前写FastAPI的时候，大多数时候都是在本地跑：

uvicorn main:app --reload

开发阶段这样很方便。

但后端项目真要提供服务，总不能一直开着笔记本。

所以我开始试着把FastAPI部署到Linux服务器上。

为什么选Linux

对后端服务来说，Linux最大的优势之一就是很适合跑长期服务。

常见的服务器环境基本都是：

Ubuntu
Debian
CentOS

个人项目里我比较喜欢用Debian。

装完之后，一个干净的Linux系统就能当运行环境用了。

装Python

先确认Python：

python3 --version

然后建项目目录：

mkdir -p /opt/my-api
cd /opt/my-api

把代码放进去。

接着建虚拟环境：

python3 -m venv .venv

激活：

source .venv/bin/activate

装依赖：

pip install -r requirements.txt

启动FastAPI

最简单的方式：

uvicorn main:app --host 0.0.0.0 --port 8000

这里的：

0.0.0.0

很重要。

如果只监听：

127.0.0.1

那服务只能被服务器自己访问。

监听：

0.0.0.0

之后，其他机器才能通过服务器IP访问。

为什么不能直接用开发模式

本地开发经常用：

uvicorn main:app --reload

--reload很适合开发。

改完代码自动重启。

但生产环境不需要这个。

生产环境更关心：

稳定
日志
自动重启
并发
安全

所以开发环境和生产环境要分开。

用systemd

如果直接在SSH窗口跑：

uvicorn main:app

关掉SSH之后，进程可能就没了。

所以得让Linux接管这个服务。

可以建：

/etc/systemd/system/my-api.service

比如：

[Unit]
Description=My FastAPI Service
After=network.target

[Service]
User=www-data
WorkingDirectory=/opt/my-api
ExecStart=/opt/my-api/.venv/bin/uvicorn main:app --host 127.0.0.1 --port 8000
Restart=always

[Install]
WantedBy=multi-user.target

然后：

systemctl daemon-reload
systemctl enable my-api
systemctl start my-api

看状态：

systemctl status my-api

这样FastAPI就成了Linux系统里的一个服务。

为什么监听127.0.0.1

这里和前面不一样。

如果后面用Nginx：

Internet
   ↓
 Nginx
   ↓
FastAPI

那FastAPI其实不用直接暴露到公网。

可以：

Nginx → 127.0.0.1:8000

这样外部用户只能访问Nginx。

这比直接把Uvicorn暴露出去更合理。

systemd最大的价值

我觉得systemd最方便的不是"启动服务"。

而是：

让服务真正成为服务器的一部分。

比如服务器重启：

服务器启动
 ↓
systemd
 ↓
自动启动FastAPI

如果程序崩了：

FastAPI崩溃
 ↓
systemd
 ↓
自动重启

这对长期运行的服务很重要。

总结

从：

本地开发
 ↓
uvicorn

到：

Linux
 ↓
systemd
 ↓
FastAPI

其实完成了一次很重要的转变。

程序不再只是"我电脑上的一个项目"，开始变成一个真正长期跑着的服务。

下一步就是解决公网访问、HTTPS和域名的问题。