企业官网建设流程全解析

去年帮朋友公司年会做过一次抽奖系统，当时用的是 Django + Celery，整套下来配置繁琐，光环境就折腾了大半天。后来遇到店面周年庆的抽奖需求，我改用了 FastAPI 在云服务器上搭了个页面抽奖服务，从初始化到上线跑通，整个过程不到两小时，而且维护成本极低。这篇文章就把整套思路和代码完整拆给你，包括抽奖概率怎么设计、库存怎么防超卖、服务怎么在云服务器上常驻运行，以及我踩过的那些坑。

这篇内容适合两类人看：一是刚接触 FastAPI 的 Python 后端开发者，想拿一个完整项目练手；二是公司或店铺有轻量抽奖需求，想快速搭一个能公网访问的页面服务。文章会尽量少讲废话，直接上可复制的代码和配置，你照着做就能跑起来。

1. 项目整体设计与思路拆解

1.1 抽奖服务的核心需求清单

开工之前，先别急着写代码，你得把需求想清楚。一个页面抽奖服务，站在使用者的角度，无非就这几件事：打开页面能看到奖品和抽奖按钮，点一下按钮等待结果，中奖了能看到提示，没中奖也有个安慰反馈。站在管理者的角度，诉求更实际：奖品总数有限，不能发超了；不同奖品中奖概率不一样，最好能配置；页面得好看，拿得出手；服务得稳定，关键时刻不能崩。

我这次的需求背景是一家线下门店做店庆，准备了五个等级的奖品和一个"谢谢参与"，活动持续三天，预计每天参与人数在几百左右。这个体量对服务端的压力不大，但对业务逻辑的正确性要求很高，因为线下活动如果出现重复中奖或者库存负数，现场很难解释清楚。

所以技术方案上我的选择是：FastAPI 负责提供抽奖接口和托管静态页面，奖品配置和库存放在一个独立的 Python 配置文件里，前端页面用一个单页 HTML 实现转盘动画，数据交互走简单的同步请求。这个组合足够简洁，也方便后续如果要接数据库，可以平滑升级。

1.2 为什么选 FastAPI 而不是 Flask 或 Node

很多人会问，同样是 Python 后端，为什么不直接用 Flask？Flask 确实简单，但 FastAPI 有几个特性在这个场景下非常实用。

第一是自动生成接口文档。FastAPI 基于 OpenAPI 标准，你只要写好类型注解，访问/docs就能拿到一个可交互的调试页面。我在现场调试抽奖接口的时候，直接在浏览器里测试请求和响应，不需要额外装 Postman，这一点真的省时间。

第二是 Pydantic 带来的参数校验。前端传过来的参与人信息，后端用类型注解就能完成格式校验，不用手写一堆 if 判断，代码干净很多。抽奖服务虽然逻辑简单，但参数校验一旦出问题，线上很容易被恶意请求刷爆。

第三是异步支持。虽然抽奖这种短操作用不上复杂的异步任务，但 FastAPI 的原生异步能力意味着，如果后续你要加短信通知、加数据落库，不需要换框架。

至于 Node 或者其他方案，也不是不行。但如果你团队以 Python 为主，FastAPI 的学习成本最低，而且这个项目本身是 IO 密集型，FastAPI 的性能完全够用。

1.3 为什么需要云服务器

本地开发环境跑得好好的，为什么非要部署到云服务器？最直接的原因是，抽奖活动需要一个公网可达的访问地址，你得让门店员工和顾客能通过手机访问页面。

我当时选了一台 2 核 2G 的云服务器，系统用的 Ubuntu 22.04。这个配置跑 FastAPI 加 Nginx 完全没问题，如果只是学习使用，甚至可以选更低的 1G 内存。有一点值得提醒：买服务器时记得留意安全组的配置规则，很多新手部署完发现访问不了，八成就是安全组没放行端口。

另外，如果服务器选在国内厂商，域名解析和备案这些流程要提前安排，免得活动当天域名用不了。我这次图省事，直接用服务器 IP 加端口的访问方式，内部活动不追求好看，能用就行。

2. 环境准备与项目初始化

2.1 云服务器初始配置清单

拿到一台全新的 Ubuntu 云服务器，先做三件事：更新系统、创建普通用户、配置基础安全策略。

sudo apt update && sudo apt upgrade -y sudo useradd -m -s /bin/bash appuser sudo usermod -aG sudo appuser

我习惯用普通用户跑应用，不用 root 直接操作。因为后面配置 systemd 服务的时候，运行用户如果设置成 root，万一应用被攻击，攻击者拿到的就是 root 权限，风险大很多。

接着确认防火墙状态。Ubuntu 默认可能装了 ufw，也可以不装，因为云厂商的安全组本身就是一层防火墙。我用的是云厂商的安全组控制规则，只在安全组里放行 22、80、443 相关端口，其他端口一律不开放。这个策略在下面的部署环节会详细说。

然后是安装 Python 环境。Ubuntu 22.04 自带的 Python 是 3.10，对于 FastAPI 来说完全够用。我建议不要动系统自带的 Python 环境，直接用 uv 创建独立虚拟环境，这样既能避免污染系统环境，也方便后续清理。

2.2 使用 uv 创建虚拟环境与安装 FastAPI

这里我用 uv 来管理虚拟环境和依赖。相比传统的 venv 加 pip，uv 的速度快很多，而且配置文件更清晰，一条命令就能创建环境并安装所有依赖。

# 安装 uv curl -LsSf https://astral.sh/uv/install.sh | sh # 创建项目目录 mkdir -p /opt/lucky-draw && cd /opt/lucky-draw # 初始化项目并创建虚拟环境 uv init uv venv # 激活虚拟环境 source .venv/bin/activate # 安装依赖 uv pip install fastapi uvicorn

如果你的环境下载慢，可以给 uv 配置国内镜像源。创建一个.uv.toml或用环境变量指定索引地址，这个按你实际情况来，不是必须的。

安装完成后可以用一行命令验证是否成功：

python -c "import fastapi; print(fastapi.__version__)"

能看到版本号就说明环境没问题了。这里要提醒一下，uv 的虚拟环境默认生成在项目目录下的.venv里，后续配置 systemd 服务时，启动命令里的 Python 路径要指向这个虚拟环境里的解释器。

2.3 项目目录结构与基础配置

整个项目的目录结构我习惯这样组织：

/opt/lucky-draw/ ├── main.py # FastAPI 入口 ├── config.py # 奖品配置与抽奖逻辑 ├── static/ │ └── index.html # 前端页面 └── requirements.txt # 依赖清单

不用拆得太碎，毕竟这个项目规模很小。config.py 里放奖品数据和抽奖算法，main.py 里放接口，static 目录放前端页面。如果以后要接数据库，再加一个 database.py 就行。

先创建一个简单的 main.py 跑通基础服务，验证环境没问题。

from fastapi import FastAPI from fastapi.staticfiles import StaticFiles app = FastAPI(title="店铺抽奖服务") @app.get("/api/health") def health_check(): return {"status": "ok"} app.mount("/", StaticFiles(directory="static", html=True), name="static")

启动服务：

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

访问http://服务器IP:8000/api/health，如果能返回 JSON 数据，说明 FastAPI 跑起来了。注意这里的--host 0.0.0.0一定要写，否则服务只在服务器本机回环地址上监听，外部无法访问。

3. 后端接口设计与抽奖逻辑实现

3.1 奖品配置与概率设计思路

抽奖最核心的部分就是概率设计。奖品分五等，加上一个未中奖选项，总共六个结果。我的配置方法是：给每个奖品指定一个权重值，抽奖时按权重随机计算，这样调整概率只需要改数字，不需要改代码。

举个例子，假设一等奖联想轻薄本比较贵重，我只打算送出 1 台，中奖概率不能太高；而五等奖是定制帆布袋，数量充足，概率可以设得高一些。具体配置如下：

# config.py PRIZES = [ {"id": 1, "name": "一等奖：轻薄本", "inventory": 1, "weight": 5}, {"id": 2, "name": "二等奖：蓝牙耳机", "inventory": 3, "weight": 10}, {"id": 3, "name": "三等奖：保温杯", "inventory": 10, "weight": 30}, {"id": 4, "name": "四等奖：公仔玩偶", "inventory": 30, "weight": 80}, {"id": 5, "name": "五等奖：定制帆布袋", "inventory": 80, "weight": 200}, {"id": 6, "name": "谢谢参与", "inventory": 999999, "weight": 675}, ]

注意 "谢谢参与" 这个伪奖品的库存我设置了一个非常大的数，相当于无限库存。权重总和是 5 + 10 + 30 + 80 + 200 + 675 = 1000，这样一等奖的概率正好是 0.5%，二等奖是 1%，三等是 3%，四等是 8%，五等是 20%，剩下 67.5% 的概率是"谢谢参与"。

为什么要用权重而不是直接写百分比？因为权重的可扩展性更好。你临时想多送几个保温杯，把 weight 从 30 改成 60，总权重变了，概率自动重新分配，不需要重新计算百分比，方便得多。

3.2 抽奖算法的完整实现

抽奖算法用random.choices实现，它支持按权重从列表里随机选择一个元素，正好对应我们的需求。

# config.py import random def normalize_weights(prizes): total_weight = sum(item["weight"] for item in prizes) return [(item["weight"] / total_weight) for item in prizes] def draw_lottery(prizes): available = [item for item in prizes if item["inventory"] > 0] if not available: return None weights = normalize_weights(available) selected = random.choices(available, weights=weights, k=1)[0] selected["inventory"] -= 1 return selected

这个实现有几个细节值得说。第一个细节是，我在随机之前先过滤了库存为 0 的奖品，这保证了库存没了就一定不会出现在候选列表里，不会出现"显示中了一等奖但库存已经没了"的尴尬情况。第二个细节是，库存扣减放在接口层还是算法层？我放在了算法层，这样即使将来接入其他入口调用，也不会漏掉扣库存这步操作。

但在高并发场景下，这段代码有个致命缺陷 —— 它不是线程安全的。如果有两个用户同时抽奖，可能会发生库存扣成负数的情况。我这次活动体量不大，这个实现够用。如果你预计并发量高，建议把库存数据放入 Redis，用DECR命令原子操作来判断是否还有库存。

3.3 抽奖接口设计与参数校验

接下来在 main.py 中新增抽奖接口。为了能追溯谁参加了活动，前端会传一个participant字段，代表参与人名称或手机号。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from config import PRIZES, draw_lottery app = FastAPI(title="店铺抽奖服务") class DrawRequest(BaseModel): participant: str class DrawResponse(BaseModel): participant: str prize: str prize_id: int @app.post("/api/draw", response_model=DrawResponse) def lottery_draw(req: DrawRequest): if not req.participant or len(req.participant) < 2: raise HTTPException(status_code=400, detail="参与人信息无效") result = draw_lottery(PRIZES) if result is None: raise HTTPException(status_code=503, detail="奖品已抽完，感谢参与") return DrawResponse( participant=req.participant, prize=result["name"], prize_id=result["id"] )

Pydantic 的BaseModel在这里做两层事：第一层是解析前端传来的 JSON 并自动校验类型，第二层是约束响应格式，避免返回多余字段。比如前端传了个{"participant": "张三"}，后端拿到后直接就能用。

关于participant的校验，我只做了最基础的长度判断，没做更严格的敏感词过滤。如果在公网环境下长期运营，建议加上频率限制和简单的去重逻辑，比如同一个手机号每天只能抽一次。这次活动在门店现场，员工会确认参与者身份，所以这个环节从简处理。

3.4 用接口文档和本地测试快速调通

启动服务后，浏览器访问http://服务器IP:8000/docs，FastAPI 自动生成的 Swagger 文档会展示所有接口。在/api/draw这个接口上点"Try it out"，输入 JSON，点执行，就能看到抽奖结果。

这个流程我在本机测试了几次，发现有个比较容易搞错的地方：@app.get和@app.post的方法不要弄混。前端抽奖是要提交数据的，所以必须用 POST，而不能用 GET。如果用 GET，前端调接口时参数只能放在 URL 上，既不安全，也不符合习惯。

本地测通了再部署到线上，这样可以减少前后端联调时来回排查的时间。我在项目里留了一个/api/health接口，方便上线后快速确认服务是否存活。

4. 前端页面设计与交互

4.1 转盘页面实现

前端我倾向于不引入前端框架，一个原生 HTML 页面搞定。原因是这个页面只承担一个功能：抽奖。用 Vue 或 React 反而要处理打包、跨域等多个额外的问题，得不偿失。

页面核心是一个 CSS 转盘，九个扇形区域，六个是奖品，三个是装饰。布局方式是用conic-gradient来画扇形背景，然后用 CSS 动画控制旋转角度。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>店铺抽奖</title> <style> body { font-family: -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif; background: linear-gradient(135deg, #ffefd5, #ffdab9); margin: 0; min-height: 100vh; display: flex; flex-direction: column; align-items: center; justify-content: center; } h1 { color: #b22222; margin-bottom: 24px; } #wheelWrapper { position: relative; width: 320px; height: 320px; margin-bottom: 20px; } #wheel { width: 320px; height: 320px; border-radius: 50%; background: conic-gradient( #ff7f50 0deg 60deg, #ffd700 60deg 120deg, #87ceeb 120deg 180deg, #98fb98 180deg 240deg, #da70d6 240deg 300deg, #f4a460 300deg 360deg ); border: 8px solid #fff; box-shadow: 0 8px 30px rgba(0,0,0,0.2); transition: transform 3.8s cubic-bezier(0.2, 0.6, 0.2, 1); cursor: pointer; } #pointer { position: absolute; top: -10px; left: 50%; transform: translateX(-50%); border-left: 15px solid transparent; border-right: 15px solid transparent; border-top: 35px solid #e74c3c; z-index: 10; } button { padding: 14px 40px; font-size: 18px; border: none; border-radius: 50px; background: #e74c3c; color: #fff; cursor: pointer; box-shadow: 0 6px 15px rgba(231, 76, 60, 0.4); } button:disabled { background: #ccc; cursor: not-allowed; } #result { margin-top: 20px; font-size: 22px; font-weight: 600; color: #333; min-height: 32px; } </style> </head> <body> <h1>幸运抽奖</h1> <div id="wheelWrapper"> <div id="pointer"></div> <div id="wheel"></div> </div> <button id="drawBtn" onclick="doDraw()">开始抽奖</button> <div id="result"></div> <script> const PRIZE_COUNT = 6; const PRIZE_ANGLE = 360 / PRIZE_COUNT; let currentDegree = 0; async function doDraw() { const btn = document.getElementById('drawBtn'); btn.disabled = true; document.getElementById('result').textContent = '开奖中，请稍候...'; const participant = prompt('请输入您的姓名或手机号后四位'); if (!participant || participant.length < 2) { alert('请填写有效的参与人信息'); btn.disabled = false; return; } try { const resp = await fetch('/api/draw', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ participant: participant }) }); const data = await resp.json(); if (!resp.ok) { throw new Error(data.detail || '抽奖失败，请重试'); } const targetAngle = calculateAngle(data.prize_id); currentDegree += 360 * 5 + targetAngle; document.getElementById('wheel').style.transform = `rotate(${currentDegree}deg)`; setTimeout(() => { document.getElementById('result').textContent = `恭喜 ${data.participant} 抽中 ${data.prize}`; }, 3800); } catch (err) { document.getElementById('result').textContent = err.message; btn.disabled = false; } } function calculateAngle(prizeId) { // 根据奖品 id 计算转盘最终停留角度，让指针指向对应扇形 const fromTop = (prizeId - 1) * PRIZE_ANGLE + PRIZE_ANGLE / 2; return (360 - fromTop) % 360; } </script> </body> </html>

转盘动画的原理是：每次抽奖在现有旋转角度上增加 5 圈（1800 度）再加上目标角度偏移，然后通过 CSS 过渡让转盘自然转动。这个方案不需要引入第三方动画库，效果也比较流畅。

4.2 页面与后端接口的数据协作

前端的fetch请求直接调用/api/draw，传一个JSON字符串，后端返回中奖结果，前端根据prize_id计算转盘要停在哪个位置。

这里有一个我踩过的坑：后端的接口地址忘了加/api前缀，导致前端始终请求 404。统一加前缀是为了以后如果要在 Nginx 里配置路径转发，只需要一个前缀就够了。前后端接口联调时，最好先把浏览器的开发者工具打开，切到 Network 面板看请求状态，能快速定位是前端问题还是后端问题。

4.3 移动端适配与按钮防重

门店场景下，用户大概率用手机访问，所以页面必须适配手机屏幕。我在 viewport 设置上用了width=device-width, initial-scale=1.0，样式里也没有固定死宽度，基本能自动适配。

真正需要重点处理的是按钮防重。用户点了一下之后，接口响应还没回来，这时候又点了第二下，就会产生并发请求，可能导致一次抽奖扣两次库存。所以我在点击后立刻禁用按钮，等抽奖结果返回后再恢复。如果请求失败，也要在 catch 里恢复按钮，否则用户会被卡在"无法抽奖"的状态。

这个防重的思路看起来简单，但很多新手会漏掉。尤其是接口报错的情况下，按钮如果一直禁用，用户找不到原因，以为系统坏了，体验很差。

5. 云服务器部署与对外访问

5.1 使用 systemd 托管 FastAPI 服务

本地运行uvicorn的方式在关闭终端后服务就停了，所以生产环境必须用进程管理器。我的方案是 systemd，这是 Linux 系统自带的服务管理工具，配置简单，支持开机自启和崩溃自动重启。

在/etc/systemd/system/lucky-draw.service创建服务文件：

[Unit] Description=Lucky Draw FastAPI Service After=network.target [Service] User=appuser WorkingDirectory=/opt/lucky-draw ExecStart=/opt/lucky-draw/.venv/bin/uvicorn main:app --host 0.0.0.0 --port 8000 Restart=always RestartSec=3 Environment=PYTHONUNBUFFERED=1 [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable lucky-draw sudo systemctl start lucky-draw sudo systemctl status lucky-draw

有几个细节需要注意。ExecStart里要写虚拟环境里的 uvicorn 绝对路径，不要直接写uvicorn，因为 systemd 的服务环境不一定加载了你的虚拟环境变量。Restart=always是保命配置，进程意外退出时会自动拉起。Environment=PYTHONUNBUFFERED=1保证 Python 日志实时输出，排查问题时不滞后。

查看日志的命令：

sudo journalctl -u lucky-draw -f

这个命令很适合现场排查。有一次我改了代码后忘了重启服务，页面一直报错，用journalctl一看才发现跑的还是旧代码，重启一下就好了。

5.2 Nginx 反向代理与静态资源托管

虽然 FastAPI 能直接托管静态文件，但生产环境我还是建议在前面加一层 Nginx。原因是 Nginx 处理静态资源的效率远高于 Python 应用，而且可以做端口转发，用户访问 80 端口就能看到页面，不用在 URL 里带:8000。

安装并配置 Nginx：

sudo apt install nginx -y

创建配置文件/etc/nginx/sites-available/lucky-draw：

server { listen 80; server_name _; location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; } }

启用配置并重载：

sudo ln -s /etc/nginx/sites-available/lucky-draw /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

这里我用了server_name _;表示匹配所有域名，如果你有自己的域名，可以把_替换成你的域名。/api/路径单独转发到 FastAPI，其余路径全部走 FastAPI 的静态文件托管。

配置完成后，用户直接访问http://IP就能看到抽奖页面，http://IP/api/draw是后端接口。

5.3 安全组和防火墙开放端口

这是最容易踩坑的环节。如果你的服务器有安全组，需要在云厂商控制台放行 80 端口（HTTP）和 22 端口（SSH）。8000 端口实际上不需要对外开放，因为 Nginx 转发的目标地址是127.0.0.1:8000，外部请求通过 80 进入 Nginx，再由 Nginx 转发给本机 8000 端口。

这样设计的最大好处是，对外只暴露一个 80 端口，FastAPI 服务本身不受外部直接访问，安全性更高。如果你不想用 Nginx，直接把 8000 端口开放也行，但页面地址就得带:8000，而且少了一层 Nginx 的静态资源加速。

5.4 域名与 HTTPS 的扩展方案

如果抽奖页面要面向公众，建议配域名和 HTTPS。Nginx 里配置好域名解析后，可以用 certbot 免费申请 SSL 证书：

sudo apt install certbot python3-certbot-nginx -y sudo certbot --nginx -d yourdomain.com

这个命令会自动修改 Nginx 配置，启用 HTTPS，并设置证书自动续期。有了 HTTPS，用户在手机浏览器访问时不会有"不安全"的警告，而且 Ajax 请求也不会因为浏览器安全策略被拦截。

如果你只是自娱自乐或者内部使用，可以跳过这一步，用 IP 直接访问就行。

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

6.1 端口不通的完整排查路径

页面打不开，是部署环节遇到最多的问题。我的排查顺序是：先看服务状态，再看防火墙，最后看安全组。

第一步，在服务器上执行curl http://127.0.0.1:8000/api/health，如果返回正常 JSON，说明 FastAPI 服务没问题。如果连本机都访问不了，检查 uvicorn 进程是否存在，查看日志有没有报错。

第二步，在本机执行curl http://服务器IP/api/health，如果通，说明服务和网络都正常，不是 80 端口的问题。如果不通，大概率是云厂商安全组没放行对应端口。

第三步，登录云厂商控制台，确认安全组入方向规则里是否有允许源地址为0.0.0.0/0、协议端口为 TCP:80 的规则。这一步最容易遗漏，因为安全组的修改即时生效，很多人以为改完就完事，结果忘了点"保存"。

6.2 跨域问题的 3 个典型场景

前后端联调时，跨域报错很常见，症状是浏览器控制台出现 CORS error。FastAPI 解决跨域的方法是使用中间件：

from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"], )

这个配置允许所有来源跨域访问，开发阶段没问题，生产环境建议把allow_origins改成一个固定的域名列表，更安全。

我遇到过的跨域场景有三类。第一种是前端页面在localhost:3000，后端在localhost:8000，端口不同导致跨域。第二种是前端页面和服务都在同一台服务器的 80 端口，但前端写了http://127.0.0.1:8000/api/draw这种绝对地址，浏览器会认为这是跨域请求。第三种是域名跳转后请求被重定向，比如请求从http://IP跳转到https://IP，也会出现跨域问题。

最省心的做法是：前端始终使用相对路径/api/draw，不要写完整的服务器地址，这样无论部署在哪里都不会跨域。

6.3 抽奖并发与库存超卖问题

活动一开始，大量用户同时点抽奖，会出现并发请求。我最初实现的draw_lottery不是线程安全的，库存扣减瞬间可能被多个请求拿到同一份库存数据，导致超卖。

要彻底解决这个问题，有两个思路。第一个思路是引入 Redis，把奖品库存放到 Redis 里，每次抽奖执行DECR命令，如果返回负数说明库存不足，就不发放该奖品。第二个思路是在库存扣减时加锁，使用 Python 的threading.Lock或者更可靠的分布式锁。

考虑到这次活动并发量不高，我用了一个简单的方案：用 FastAPI 的同步接口特性，因为同步函数在运行时会占用线程池中的一个线程，而draw_lottery函数里的操作非常快，同一时刻能进入抽奖函数的并发量很有限。如果你预计高并发，建议直接上 Redis 方案，代码也不复杂。

6.4 热更新失效与日志排查

本地开发时，uvicorn main:app --reload可以热更新，但生产环境我强烈不建议用--reload。因为每次文件变动会自动重启，如果代码有语法错误，服务就会一直重启失败。而且--reload模式下进程会多一个监听文件变化的子进程，白白消耗系统资源。

正确的流程是：改完代码后，执行sudo systemctl restart lucky-draw手动重启，然后看journalctl -u lucky-draw -f的日志确认启动成功。

日志排查有个小技巧：在接口里加一些关键日志，比如每次抽奖请求都打一条日志，记录参与人和中奖结果。这样一旦现场反馈"抽不了奖"，你可以通过日志快速定位问题是出在请求到达、参数校验、还是抽奖逻辑自身。

7. 最终效果与个人心得

整个项目跑通后，我还在本地做了一次简单的压力测试，用并发工具模拟了 50 个用户同时抽奖，观察库存和响应时间。结果是库存数据没有出现负数，接口平均响应时间在 20ms 以内，表现良好。当然，这个测试只验证了当前低并发量下的稳定性，如果你要服务几千人同时在线，需要更严谨的压测和架构设计。

最后分享一个我在实际部署中的个人经验：不要把代码直接放在服务器的/root目录下，也不要直接测试时用root用户跑 uvicorn。我给 FastAPI 服务单独创建了appuser用户，目的就是万一应用存在安全漏洞，攻击者拿到的权限也是受限制的。这个习惯在个人项目里可能显得多余，但如果是给公司做系统，安全审计的时候这就是一条明确的加分项。

另一个小技巧是：博文里提到的config.py中奖品配置，我后来把库存和概率改成了从数据库读取，方便活动期间实时调整。如果只是临时活动，纯配置文件完全够用；如果想长期运营，建议把配置落地到数据库或配置中心，避免每次改奖品都要 ssh 上服务器编辑文件。

搭建这个抽奖服务的整体流程并不复杂，关键是每个环节都要理解为什么这么做。FastAPI 帮你省了很多重复工作，但在部署、安全、并发这些工程问题上，还是得自己把关。按这篇文章一步步来，你也能在两个小时内拥有一个能用的线上抽奖服务。