技术栈选择理由
去年开始为日照经开区一家物流公司开发内部管理系统（TMS运输管理系统）。技术选型定为后端Python FastAPI + 前端Vue 3 + Element Plus。下面记录这套组合在实际开发中的体验。
FastAPI后端经验
为什么选FastAPI而不是Django/Flask
- 自动生成API文档（Swagger UI开箱即用，和前端联调极其方便）
- 异步支持原生（async/await，IO密集型场景性能出色）
- 类型提示（Pydantic模型做请求/响应校验，减少大量if判断）
- 性能好（基于Starlette，接近Go框架的性能）
- 学习成本低（如果你懂Python和Flask，一天就能上手）
项目结构
推荐的目录组织方式如下：
app/main.py- 入口文件app/config.py- 配置管理app/models/- 数据库模型(SQLAlchemy)app/schemas/- Pydantic模型app/api/- 路由模块（含auth/orders/vehicles）app/services/- 业务逻辑层app/utils/- 工具函数app/middleware/- 中间件
踩过的坑
坑一：FastAPI的依赖注入系统很强大但过度使用会让代码难以理解。建议只在认证/数据库session/权限校验等跨切面的场景使用依赖注入。
坑二：async模式下不能使用同步的SQLAlchemy ORM（会阻塞事件循环）。解决方案是用encode/databases异步驱动或SQLAlchemy 2.0的async模式。
坑三：Pydantic v2和v1的API有一些不兼容的地方，注意文档版本。
Vue 3前端经验
状态管理
项目不大所以没用Vuex/Pinia，直接用composable函数+provide/inject做状态共享。如果项目更大还是会推荐Pinia。
API调用封装
基于axios封装了一个request模块：统一baseURL/请求拦截器（加token）/响应拦截器（401跳登录/500错误提示）/请求取消/loading状态管理。
表格 CRUD 的通用方案
管理系统里有大量的列表/搜索/新增/编辑/删除页面。抽象了一个useTable composable：传入API接口自动获得data/loading/pagination/search/handleAdd/handleEdit/handleDelete等方法。每个CRUD页面只需几十行代码。
部署方案
- 后端：Gunicorn + Uvicorn workers（4 worker进程）
- 前端：npm run build生成静态文件，Nginx直接托管
- Nginx配置：/api路径proxy_pass到后端8000端口，其他路径serve前端静态文件
- 数据库：MySQL 8.0 + Redis（缓存+session）
- Supervisor管理进程守护
- 服务器：阿里云ECS 4核8G（日照本地延迟约8ms）
性能数据
系统上线运行6个月，日均PV约3000（内部50人使用）：API平均响应时间85ms/页面切换感觉瞬间完成/concurrent 50用户无压力。客户满意度很高，已经续签了二期开发合同。