毕设Python效率提升实战：从脚本到可维护项目的工程化重构指南
1.个把月写完的脚本，为什么越跑越慢？
做毕设时，大家习惯“先跑起来再说”：一个main.py写到底，全局变量随手甩，数据来了就for循环，结果——
- 代码混乱：函数平均长度 200+ 行，调试靠
print，改一行逻辑要翻半小时。 - 重复计算：每次请求都把 3 G raw 数据重新清洗，CPU 100 % 风扇起飞。
- 无日志监控：本地跑得好好的，到服务器上 502 了，却找不到哪一步崩了。
这些问题在答辩前一周集中爆发，于是“通宵改 bug”成为常态。下面把我亲测有效的重构路线拆给大家，跟着做，基本能把迭代周期缩短一半，性能翻两倍。
2.技术选型：别在 Hello World 阶段就把路走窄
先给结论，再讲原因：
| 场景 | 推荐 | 理由 |
|---|---|---|
| Web 接口 | FastAPI | 异步原生、类型提示、自动生成 OpenAPI 文档，写毕设报告直接截图 |
| 数据库 | PostgreSQL + SQLModel | 毕设后期要加字段、上索引、做并发，SQLite 锁等待会教你做人 |
| 长耗时任务 | Celery + Redis | 把同步阻塞换成异步消息队列，前端点一下按钮即可后台慢慢跑 |
| 数据科学 | Polars + concurrent.futures | 比 pandas 省内存，多线程 IO 不踩 GIL，十万行 CSV 秒级读完 |
如果导师只要求“能跑”，可以先用 Flask+SQLite；但要想“跑得又快又稳”，直接上 FastAPI+PostgreSQL 最省心，后期加鉴权、限流、WebSocket 都方便。
3.目录结构：让后来者 30 秒看懂你的代码
把“一次脚本”拆成“可安装 Python 包”，推荐如下模板：
gradproj/ ├── app/ # 主包 │ ├── api/ # 路由层 │ ├── core/ # 配置、依赖、工具 │ ├── models/ # ORM 模型 │ ├── services/ # 业务逻辑 │ └── tasks/ # Celery 异步任务 ├── scripts/ # 一次性数据迁移脚本 ├── tests/ # pytest 单元测试 ├── docker-compose.yml ├── pyproject.toml # 依赖、脚本入口、black/isort 规则 └── README.md要点：
- 所有业务函数放
services，禁止在路由里写 SQL。 core/config.py用 PydanticBaseSettings一次性读.env，类型不对直接抛错，杜绝“配置写错跑半天”。scripts与正式代码隔离，数据清洗脚本再乱也不影响主包。
4.配置分离：把“写死”的魔法数赶到环境变量
以前每换一台机器就要改三处路径？重构后只需改.env：
# app/core/config.py from pydantic import BaseSettings class Settings(BaseSettings): database_url: str = "postgresql+asyncpg://user:pass@localhost/gradproj" redis_url: str = "redis://localhost:6379/0" celery_result_backend: str = "redis://localhost:6379/1" class Config: env_file = ".env" settings = Settings()FastAPI 的依赖注入可以把它挂到全局：
# app/core/dependencies.py from functools import lru_cache from app.core.config import Settings @lru_cache def get_settings() -> Settings: return Settings()这样测试时直接monkeypatch环境变量即可，无需改代码。
5.并发加速：concurrent.futures 实战示例
假设要对 100 份 CSV 做聚合，每份 200 MB，单线程 20 分钟。改成线程池 + Polars，2 分钟搞定：
# scripts/batch_agg.py import polars as pl from concurrent.futures import ThreadPoolExecutor, as_completed from pathlib import Path SRC = Path("data/raw") DST = Path("data/agg") DST.mkdir(exist_ok=True) def process_one(file: Path) -> None: df = pl.read_csv(file) out = ( df.groupby("station_id") .agg([pl.col("temperature").mean(), pl.col("humidity").mean()]) ) out.write_parquet(DST / f"{file.stem}.parquet") def main(): files = list(SRC.glob("*.csv")) with ThreadPoolExecutor(max_workers=8) as pool: futures = [pool.submit(process_one, f) for f in files] for f in as_completed(futures): # 这里抛异常会立刻感知，避免静默失败 f.result() if __name__ == "__main__": main()注意：
- IO 密集用
ThreadPoolExecutor即可，CPU 密集再上ProcessPoolExecutor。 - Polars 的 API 与 pandas 类似，但底层零拷贝，内存占用降 60 %。
6.缓存策略：Redis 当“中间层”，别让同一查询锤爆数据库
毕设里常见的“查询历史趋势”接口，参数一样却每次都要重新算。加一层缓存，响应从 1.2 s 降到 30 ms：
# app/services/trend.py import json import redis from app.core.config import settings r = redis.from_url(settings.redis_url, decode_responses=True) def get_trend(station_id: str, days: int): key = f"trend:{station_id}:{days}" if (data := r.get(key)) is not None: return json.loads(data) # 缓存未命中，查数据库并回写 df = query_db(station_id, days) data = df.to_dict(orient="records") r.set(key, json.dumps(data), ex=600) # 10 分钟过期 return dataFastAPI 路由里直接调用get_trend，前端毫无感知。实测 100 并发，缓存命中率 92 %，数据库 QPS 从 1200 降到 100。
7.性能测试：本地打一轮压测再上线
工具用httpx + pytest-asyncio即可，示例：
# tests/load/test_trend.py import httpx import pytest @pytest.mark.asyncio async def test_trend_load(): async with httpx.AsyncClient(base_url="http://127.0.0.1:8000") as client: for _ in range(1000): r = await client.get("/api/trend", params={"station_id": "A01", "days": 7}) assert r.status_code == 200本地 4 核 16 G 笔记本结果：
| 指标 | 重构前 | 重构后 |
|---|---|---|
| 平均响应 | 1.2 s | 0.18 s |
| p95 | 2.1 s | 0.25 s |
| 内存峰值 | 1.8 G | 0.7 G |
8.安全性：最容易丢分的“输入校验”
- 路径参数用正则限制，如
station_id: str = Path(..., regex=r"^[A-Z0-9]{3,8}$")。 - 敏感配置（DB 密码、JWT 密钥）绝不进 Git，用 GitHub Secret 或 GitLab CI/CD Variable。
- 全局异常捕获，统一返回 JSON，禁止把栈信息抛给前端，防止泄露路径结构。
9.生产环境避坑清单
- 避免全局变量存状态：多 worker 下互相隔离，用数据库或 Redis 做共享。
- 幂等性：异步任务重试时，用“结果标记”或“唯一索引”保证重复执行不翻倍写数据。
- 冷启动延迟：Docker 镜像里预装
uvloop，gunicorn -k uvicorn.workers.UvicornWorker能把 FastAPI 启动时间从 4 s 降到 1 s。 - 日志轮转：用
logging.handlers.RotatingFileHandler，防止一个out.log把磁盘打爆。 - 备份策略：PostgreSQL 每天
pg_dump到对象存储，毕设答辩前硬盘坏了也能 10 分钟回血。
10.动手重构：三步走，今晚就能跑起来
- 把“能跑”脚本拆成函数，按“输入-处理-输出”贴到
services。 - 用
concurrent.futures或 Celery 把长任务挪出请求生命周期。 - 写一份
pytest，至少把主流程跑通，再配 GitHub Actions 自动跑测试。
重构完，你会明显感觉“加功能”不再畏手畏脚——因为模块边界清晰，改 A 不碰 B，回滚也有 git 兜底。
11.写在最后：速度 vs 可维护，其实可以双赢
毕设时间紧，很多人担心“工程化”会拖慢节奏。我的经验是：前期花 2 小时搭好骨架，后期每天都能省 30 分钟找 bug 时间，总账反而划算。下次动手前，不妨先问自己：
- 这段代码如果半年后回头看，能 5 分钟看懂吗？
- 如果数据量翻 10 倍，现在这份实现撑得住吗？
把这两个问题带入开发节奏，你就能在“开发速度”与“长期可维护”之间找到属于自己的平衡点。祝你毕设一遍过，代码常新，风扇不转。
