尧图网站建设 
从居家办公成为企业常态那一天起文档管理就不再是把文件存进共享文件夹这么简单了。团队分散在各家各户一个项目方案从初稿到终稿往往要经历七八次修改最终版本散落在不同人的电脑里主管想审批一份报告得在微信聊天记录里爬楼新同事入职连项目文档在哪找都不知道。我做这个pythonVUE企业员工居家在线办公文档管理系统的设计与实现项目就是为了把文档的采集、存储、版本、权限、归档这一整条链路理顺。本文会按照项目的实际推进顺序从需求拆解到技术选型从数据库设计到前后端实现再到联调和部署把完整的思路和关键代码逻辑完整整理出来。想拿这个题目做毕业设计或者计划给团队搭一套内部文档系统的开发同学可以直接参考这套落地路径。1. 居家办公场景下文档管理到底要管什么1.1 先理解居家办公和坐在办公室里管理文档的差异做这个系统之前我先把传统办公和居家办公的文档使用场景做了个对比。道理很简单使用场景变了系统设计的前提就不一样。在办公室场景中文件传输主要靠U盘拷贝和共享文件夹网络环境稳定同事之间的沟通链路短。一旦转到居家办公立刻出现几个新问题一是员工之间物理隔离文件只能走线上传输但线上传输工具的版本管理能力几乎为零微信传文件传到最后经常出现最终版v2(1).docx这种命名惨案二是文档的权限边界变得模糊很多敏感文件在没有控制的渠道里流转出问题根本追溯不到源头三是不在同一个办公网时员工需要从外部访问企业内网的文档资源这对系统的网络访问方式提出了要求。所以这个系统在设计之初就没有简单定成一个文件上传和下载的工具而是奔着让文档像在企业内网一样有序流转去做的。核心要解决的三个问题是文档存得下可靠的存储、找得到分类和搜索、用不滥权限和日志。1.2 角色和功能模块怎么拆我把系统的使用者拆成了三个角色普通员工、部门主管、系统管理员。三个角色的权限不同界面呈现的重点也不同。普通员工上传文档、下载文档、维护自己上传的文档、查看操作记录。部门主管拥有普通员工全部权限还能查看本部门的文档库、浏览部门内员工的上传记录、对文档进行归档或下架处理。系统管理员用户管理、分类管理、全库文档管理、操作日志审计、系统参数配置。围绕这三个角色功能模块可以拆成下面这张表功能模块子功能说明用户认证登录、登出、密码修改JWT无状态认证支持跨域调用文档管理上传、下载、删除、修改支持单文档多版本分类管理多级分类、分类维护如行政类、技术类、人事类版本管理新增版本、版本列表、版本回滚保留历史快照可追溯搜索筛选关键字搜索、分类筛选、时间排序提升大量文档下的查找效率操作日志记录关键操作、审计查询谁在什么时间做了什么操作权限控制基于角色的权限隔离员工只能操作自己有权限的文档这套模块拆完之后系统的边界就清楚了。没有做在线编辑功能也没有做复杂的工作流审批因为文档管理和文档协作是两个量级的产品在设计与实现这个规模下把存储、版本、权限、日志做扎实就已经能覆盖居家办公的核心痛点。1.3 提前约定非功能需求除了功能需求我在动手前还给自己定了几条非功能约束这些约束直接影响技术选型和数据库设计。文件上传大小单文件上限设定为100MB。居家办公环境下大文件如设计稿、录屏视频也比较常见。并发要求按中小型团队设计预计同时在线人数50人以内避免过度设计。安全要求密码存储必须加密、上传文件必须校验类型、操作必须留痕。部署环境考虑到成本计划部署在一台2核4G的云服务器上因此前后端要分离部署、静态文件要交给Nginx托管。这些约束让后续的每一步选择都变得有据可依不会为了炫技引入不必要的复杂度。2. 技术栈落地为什么是Django Vue3而不是Flask Vue2说实话一开始我也在Flask和Django之间犹豫过。网上Python后端框架的对比文章一大把但真正落到自己的项目里核心判断维度就那么几个开发效率、内置功能、生态成熟度、调试方便程度。2.1 后端选Django的理由对于文档管理系统这种典型的管理信息系统Flask确实能写而且写起来很自由。但自由是有代价的数据库迁移要自己配、Admin后台要自己搭、用户认证要自己画、ORM要自己挑。一堆决策做完可能还没开始写业务代码。Django的优势在于官方已内置。Django自带的ORM、Admin后台、User认证体系、表单校验、中间件机制几乎就是为管理类系统量身定做的。尤其是Admin后台在开发阶段可以直接用它来管理用户、查看数据调试效率极高。最终选定的版本组合是Python 3.10 Django 4.2 Django REST Framework SimpleJWT。Django 4.2是当前比较稳定的版本DRF负责把MVT转换成更符合前后端分离习惯的API接口SimpleJWT用来提供无状态的Token认证。这个组合在社区里非常成熟遇到问题基本都能搜到解法这一点对做毕业设计或新手项目来说非常重要。2.2 前端选Vue3的理由前端框架没什么悬念选Vue 3。热词里大量出现vue安装及环境配置vue路由vue computed说明Vue生态的入门资料已经足够丰富真要遇到Vue3的语法细节问题文档和社区都能兜底。Vue 3正式版发布以来组合式APIComposition API带来的代码组织方式改进非常明显。对文档管理这种以页面为核心的中后台项目用组合式API可以把某个业务功能的响应式数据、计算属性、方法函数聚在一起逻辑更清晰。再搭配上Vite作为构建工具开发环境的启动速度比Webpack快了不只一个档次。UI组件库选了Element Plus。这是Vue 3生态里最成熟的桌面端组件库表格、上传、分页、对话框这些后台管理系统的常客都有现成组件能省掉大量手写样式的时间。2.3 前后端分离的架构约定整个项目采用前后端分离架构前端是独立的Vue应用通过HTTP请求调用后端API。后端只负责提供JSON数据接口前端只负责渲染页面和交互两者通过接口文档进行契约约定。为了让接口风格统一我简单的设计如下约定接口统一前缀/api/数据返回格式统一为{code: 200, message: success, data: {...}}文件上传使用multipart/form-data格式提交文件下载使用二进制流返回前端按blob处理这套约定在后端写API的时候就要严格遵守不然前后端联调阶段会有吐不完的槽。3. 数据库设计五张核心表如何覆盖文档全生命周期3.1 实体关系梳理文档管理系统的核心数据实体我梳理出来是五张表用户表、分类表、文档表、版本表、操作日志表。用户和文档是一对多关系一个用户上传多份文档文档和版本是一对多关系一份文档可以有多个历史版本文档和分类是多对一关系一份文档归属一个分类用户和操作日志是一对多关系一个用户产生多条日志。关系理清楚之后表结构的设计就水到渠成了。3.2 核心表结构用户表直接继承Django自带的AbstractUser在原有字段基础上扩展了部门、角色等业务字段没有自己从零建既省事又安全。字段类型说明idint主键usernamevarchar用户名唯一passwordvarchar密文存储departmentvarchar所属部门rolevarchar角色admin / manager / staffphonevarchar手机号is_activebool是否启用文档分类表支持多级分类用parent_id自关联。字段类型说明idint主键namevarchar分类名称parent_idint父级分类ID0为顶级sort_orderint排序权重create_timedatetime创建时间文档表是整个系统的核心。字段类型说明idint主键titlevarchar文档标题descriptiontext文档描述file_pathvarchar文件存储路径file_typevarchar文件类型file_sizebigint文件大小字节categoryint外键所属分类uploaderint外键上传者current_versionvarchar当前版本号statusvarchar状态draft / published / archiveddownload_countint下载次数create_timedatetime创建时间update_timedatetime更新时间版本表记录文档的每一次变更。字段类型说明idint主键documentint外键所属文档version_numvarchar版本号file_pathvarchar该版本文件路径change_notetext更新说明create_timedatetime创建时间uploaderint外键上传人操作日志表做最简单的流水记录。字段类型说明idint主键userint外键操作人actionvarchar操作类型doc_idint文档IDdetailvarchar操作详情ip_addressvarchar操作IPcreate_timedatetime操作时间3.3 为什么文档和版本一定分表这是设计阶段比较重要的一张判断。很多第一次做文档系统的人会把文件直接替换成一份新的旧文件覆盖掉这样做最简单但会让系统失去追溯能力。版本管理是这个系统的核心价值之一如果员工上传了一份错误的文件管理员要把系统里已上传的错误文件找回来版本回滚是唯一能救命的方案。所以我坚持把文档本身和它的历史版本分成两张表。文档表存的是当前状态版本表存的是历史快照。当用户上传新版本时逻辑上是这样的文档表里的file_path和current_version更新到新文件旧文件的路径和元数据则插入到版本表中。这样既能保证文档列表查询的高效又能完整保留每一次变更痕迹。后面的接口代码里会再细说这个逻辑。4. 后端实现上传、下载、版本、权限四条主线的关键代码4.1 项目初始化Django项目的骨架初始化是很标准的操作。创建虚拟环境、安装依赖、django-admin startproject、python manage.py startapp docs、startapp users、startapp logs按模块拆分成三个应用职责边界清晰。关键依赖写入requirements.txtDjango4.2 djangorestframework3.14 djangorestframework-simplejwt5.2 django-cors-headers4.0 Pillow10.0在settings.py里需要做几处关键配置把rest_framework、corsheaders、docs、users、logs注册进INSTALLED_APPS配置DRF的默认认证类为JWT配置媒体文件的保存路径。文件上传会保存到media目录下MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media4.2 模型定义了系统的地基文档模型的关键字段设计我按照前面数据库设计部分的表格来实现。需要注意的一个细节是file_path字段存的是相对路径而非绝对路径这样部署在不同环境时只需要修改MEDIA_ROOT配置不必动数据库里的数据。from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): DEPARTMENT_CHOICES [ (tech, 技术部), (hr, 人事部), (finance, 财务部), (admin, 行政部), ] ROLE_CHOICES [ (staff, 员工), (manager, 主管), (admin, 管理员), ] department models.CharField(max_length50, choicesDEPARTMENT_CHOICES, blankTrue) role models.CharField(max_length20, choicesROLE_CHOICES, defaultstaff) phone models.CharField(max_length20, blankTrue) class DocCategory(models.Model): name models.CharField(max_length100) parent models.ForeignKey(self, nullTrue, blankTrue, on_deletemodels.CASCADE) sort_order models.IntegerField(default0) create_time models.DateTimeField(auto_now_addTrue) class Document(models.Model): STATUS_CHOICES [ (draft, 草稿), (published, 已发布), (archived, 已归档), ] title models.CharField(max_length200) description models.TextField(blankTrue) file models.FileField(upload_todocuments/%Y/%m/) file_type models.CharField(max_length50, blankTrue) file_size models.BigIntegerField(default0) category models.ForeignKey(DocCategory, on_deletemodels.SET_NULL, nullTrue) uploader models.ForeignKey(User, on_deletemodels.CASCADE, related_namedocuments) current_version models.CharField(max_length20, defaultv1) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultdraft) download_count models.IntegerField(default0) create_time models.DateTimeField(auto_now_addTrue) update_time models.DateTimeField(auto_nowTrue) class DocumentVersion(models.Model): document models.ForeignKey(Document, on_deletemodels.CASCADE, related_nameversions) version_num models.CharField(max_length20) file models.FileField(upload_todocuments/versions/%Y/%m/) change_note models.TextField(blankTrue) uploader models.ForeignKey(User, on_deletemodels.SET_NULL, nullTrue) create_time models.DateTimeField(auto_now_addTrue) class OperationLog(models.Model): user models.ForeignKey(User, on_deletemodels.SET_NULL, nullTrue) action models.CharField(max_length50) doc_id models.IntegerField(nullTrue, blankTrue) detail models.CharField(max_length500, blankTrue) ip_address models.GenericIPAddressField(nullTrue) create_time models.DateTimeField(auto_now_addTrue)FileField是Django处理文件上传的核心。它会把文件写入MEDIA_ROOT对应的目录并把相对路径保存到数据库字段里。upload_to参数里加了%Y/%m/文件会自动按年和月归档到不同子目录避免一个目录下文件过多。4.3 上传接口的逻辑链DRF中写上传接口最常规的设计是序列化器配合通用视图。上传接口的核心逻辑不只是把文件存下来还包括校验文件类型、限制文件大小、识别文件类型然后才保存记录。时间关系接口代码用函数视图演示会更清晰from rest_framework.decorators import api_view, permission_classes from rest_framework.permissions import IsAuthenticated from django.core.exceptions import ValidationError ALLOWED_EXTENSIONS [pdf, doc, docx, xls, xlsx, ppt, pptx, txt, png, jpg, jpeg, zip] MAX_FILE_SIZE 100 * 1024 * 1024 # 100MB api_view([POST]) permission_classes([IsAuthenticated]) def upload_document(request): file request.FILES.get(file) title request.data.get(title, ) category_id request.data.get(category_id, None) if not file: return Response({code: 400, message: 未上传文件}, status400) ext file.name.split(.)[-1].lower() if ext not in ALLOWED_EXTENSIONS: return Response({code: 400, message: 不支持的文件类型}, status400) if file.size MAX_FILE_SIZE: return Response({code: 400, message: 文件大小超出限制}, status400) doc Document.objects.create( titletitle or file.name, filefile, file_typeext, file_sizefile.size, uploaderrequest.user, category_idcategory_id, current_versionv1 ) OperationLog.objects.create( userrequest.user, actionupload, doc_iddoc.id, detailf上传文档{doc.title}, ip_addressrequest.META.get(REMOTE_ADDR) ) return Response({code: 200, message: 上传成功, data: {doc_id: doc.id}})文件类型校验这一层不能省。虽然前端也做了限制但恶意请求完全能绕过前端直接打到后端接口后端不校验就等于裸奔。下载接口要考虑的细节是download_count的递增。为了性能这个字段不需要强一致每次下载加一即可不会对系统正确性造成影响。4.4 版本管理的核心新增与回滚新增版本的逻辑可以概括为三步把文档表当前的file数据快照到版本表、把文档表的file和current_version更新为新文件、在版本表插入一条新版本记录。具体实现时有一个先后顺序问题很重要一定要先把旧文件信息保存到版本表然后再覆盖文档表的文件字段顺序搞反就会丢失历史数据。api_view([POST]) permission_classes([IsAuthenticated]) def add_version(request, doc_id): doc Document.objects.get(iddoc_id) # 校验当前用户是否有操作权限略 file request.FILES.get(file) if not file: return Response({code: 400, message: 未上传文件}, status400) # 旧版本快照 DocumentVersion.objects.create( documentdoc, version_numdoc.current_version, filedoc.file, change_noterequest.data.get(change_note, ), uploaderrequest.user ) # 更新文档主表 version_num v str(len(doc.versions.all()) 1) doc.file file doc.current_version version_num doc.file_size file.size doc.file_type file.name.split(.)[-1].lower() doc.save() return Response({code: 200, message: 版本更新成功, data: {version_num: version_num}})版本回滚逻辑刚好相反从版本表里取回指定版本的记录把它还原成一个新版本写入当前文档同时保留当前版本作为快照。这里我采用的是回滚即产生新版本的策略而不是简单地把字段覆盖回去这样每次操作都有完整记录符合审计要求。权限校验我用的是自定义装饰器。最基础的代码思路是def role_required(allowed_roles): def decorator(view_func): wraps(view_func) def _wrapped_view(request, *args, **kwargs): if request.user.role not in allowed_roles: return Response({code: 403, message: 没有权限执行该操作}, status403) return view_func(request, *args, **kwargs) return _wrapped_view return decorator对于员工文档删除这类操作还需要额外的属主校验普通员工只能操作自己上传的文档主管可以操作本部门所有文档管理员可以操作所有文档。没有这套控制居家办公场景下的权限混乱问题根本没解决。5. 前端实现Vue3 Element Plus搭出可用的文档管理台5.1 工程初始化与目录规划前端工程我用Vite搭建。执行npm create vuelatest按提示选择Vue Router、Pinia、ESLint等选项。项目目录按模块组织没有用默认的views一锅端而是按业务维度划分src/ ├── api/ # 接口请求封装 │ ├── auth.js │ └── document.js ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── stores/ # Pinia状态管理 ├── views/ # 页面组件 │ ├── LoginView.vue │ ├── HomeView.vue │ ├── DocumentListView.vue │ ├── DocumentDetailView.vue │ ├── VersionListView.vue │ └── LogView.vue ├── utils/ # 工具函数 └── main.jsapi/目录把接口调用单独封装页面组件里不直接写请求地址这是一个值得坚持的小习惯。后面前端组件只调用import { getDocList } from /api/document可读性和可维护性都高很多。5.2 路由与状态管理路由配置需要区分角色未登录用户只能访问登录页管理员和普通员工能访问的菜单不同。简单的做法是在路由配置文件里加一个meta字段来标记所需权限然后在router.beforeEach守卫里做判断。const routes [ { path: /login, component: LoginView }, { path: /documents, component: DocumentListView, meta: { requiresAuth: true } }, { path: /logs, component: LogView, meta: { requiresAuth: true, roles: [admin] } } ] router.beforeEach((to, from, next) { const token localStorage.getItem(access_token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })用户状态用Pinia来管理。登录成功之后把用户信息和Token写入store页面刷新的时候再从localStorage恢复。Token的存取参考了业界惯例access_token有效期短2小时refresh_token有效期长7天前端请求拦截器在遇到401时尝试刷新Token刷新成功就重放原请求。5.3 文档列表页的核心交互文档列表页是这个系统前端的关键页面。Element Plus的el-table组件负责表格渲染el-pagination负责分页。上传功能我用el-upload组件实现。一个容易踩坑的细节是el-upload和自定义后端接口对接时不要把文件交给组件内部的action自动上传而是设置http-request自定义上传函数把文件交给我们的axios实例处理这样Token才能正确注入到请求头。el-upload :show-file-listfalse :http-requesthandleUpload accept.pdf,.doc,.docx,.xls,.xlsx el-button typeprimary上传文档/el-button /el-upload script setup const handleUpload async (options) { const formData new FormData() formData.append(file, options.file) formData.append(title, titleRef.value) formData.append(category_id, categoryIdRef.value) const res await uploadDocument(formData) if (res.data.code 200) { ElMessage.success(上传成功) fetchList() } } /script列表页的数据加载逻辑不算复杂但是要处理好加载状态、数据刷新、以及列表项里的操作按钮权限控制。普通员工进入页面时文档列表只显示自己可见的文档主管可以切换部门筛选管理员能看到全局数据。这些权限状态在Pinia里维护视图里通过v-if判断避免权限泄露。5.4 下载与预览的交互处理文件下载在前端不能直接用一个a标签跳转因为后端接口需要Token认证直接跳转会把Token丢失。正确的做法是用axios设置responseType: blob拿到二进制流后用URL.createObjectURL生成临时链接再触发下载。这个过程有一个我调了很久的坑后端返回的文件名如果带中文直接放在Content-Disposition头里会被浏览器识别成乱码需要在前端解析文件名时做一次decode处理。在线预览功能我只实现了图片、[纯文本]、PDF三类视频和Office文件预览依赖Office Online服务受限于服务稳定性并没有集成。图片预览直接打开el-image的预览模式文本和PDF则通过iframe加载blob URL实现简单但够用。6. 前后端联调跨域、Token、文件流三个必踩的坑6.1 跨域问题的根源与配置开发环境下前端跑在5173端口后端跑在8000端口不同源跨域问题第一轮联调就出现了。前端的控制台直接报错CORS policy: No Access-Control-Allow-Origin header is present。这个问题的解决很简单后端安装django-cors-headers在settings.py中配置允许的源。INSTALLED_APPS [ ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://127.0.0.1:5173, ]需要注意CorsMiddleware要放在CommonMiddleware之前才能正常工作。开发环境只允许本地地址生产环境要换成服务器的域名或IP不要把CORS_ALLOW_ALL_ORIGINSTrue带到生产环境。6.2 Token注入与401刷新axios请求拦截器里统一注入Token这是最常见的做法service.interceptors.request.use(config { const token localStorage.getItem(access_token) if (token) { config.headers.Authorization Bearer ${token} } return config })响应拦截器中需要处理两个问题一是Token过期时返回401自动调用刷新接口二是业务层面的错误码处理。当时我遇到一个很隐蔽的问题JWT的刷新接口在Token过期后第一次调用就报错排查出来是SimpleJWT默认的刷新令牌有效期是24小时而我设置的过期时间超过了这个值。后来统一把刷新令牌有效期调成7天并且前端把refresh_token和access_token分开存储。6.3 文件流下载的中文文件名文件下载时遇到的编码问题是联调阶段最耗时的一个。我的后端代码设置了Content-Disposition: attachment; filenamexxx.pdf但如果是中文文件名浏览器收到的头会被RFC 5987编码规则限制。解决办法是后端使用quote对文件名做编码同时生成一个filename*字段前端在解析时也要做对应处理。from urllib.parse import quote filename 项目方案终稿.pdf disposition fattachment; filename*UTF-8{quote(filename)} response[Content-Disposition] disposition这个坑很典型单看后端接口返回正确单看前端逻辑正确但从浏览器角度验证就是乱码。联调阶段一定要用浏览器开发者工具直接观察响应头别只盯着Network里的状态码和响应体。6.4 大文件上传100MB以内的文件直接走普通的multipart上传问题不大。但实测过程中发现公司里设计部门的PSD文件往往能到几百MB甚至1GB超过限制用户就会投诉。考虑到这个项目定位是中小型团队内部系统我把单文件限制调到了500MB并增加了分片上传的后续优化方案。分片上传的思路其实不复杂前端把文件按固定大小比如5MB切片逐片上传后端记录每个切片的状态全部上传完成后触发合并。切片上传的好处是支持断点续传网络中断后不用重新上传整个文件。但完整做下来要配合后端增加合并文件接口、设计切片编号、处理并发顺序工作量并不小。我在当前的毕业设计版本里保留了普通上传方案分片上传作为后续优化方向在系统设计文档中做了说明。7. 部署到服务器居家办公场景下的远程访问方案7.1 后端部署后端部署我选的是Gunicorn作为WSGI服务器。先在服务器上创建虚拟环境安装依赖做数据库迁移然后启动Gunicorn监听127.0.0.1:8000端口。cd /opt/doc_system/backend source venv/bin/activate pip install -r requirements.txt python manage.py migrate python manage.py collectstatic --noinput gunicorn config.wsgi:application -b 127.0.0.1:8000 -w 4 --timeout 60-w 4表示4个worker进程一台2核4G服务器跑这个配置并发扛几十个用户够用。--timeout 60是因为文件上传接口有时超过默认的30秒需要延长超时时间否则大文件上传容易超时被杀。7.2 前端构建与Nginx反向代理前端构建生成静态文件上传到服务器的/opt/doc_system/frontend目录。Nginx负责两件事一是托管前端静态文件二是把/api/的请求反向代理到后端Gunicorn进程。server { listen 80; server_name your-domain.com; # 前端静态文件 root /opt/doc_system/frontend; index index.html; # 历史路由支持Vue Router启用history模式需要 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 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; proxy_read_timeout 300s; } # 上传文件访问 location /media/ { alias /opt/doc_system/backend/media/; } }location /中的try_files配置是Vue Router使用history模式时的刚需没有它刷新页面就会404。手动测一下能绕开这个问题。7.3 居家远程访问云服务器是首选方案居家办公环境下员工需要从外部网络访问内部系统访问方案在设计之初就要想清楚。我的建议是把系统部署到一台具有公网IP的云服务器上员工通过域名或公网IP访问。这是最稳定也最干净的方式。如果团队预算有限也可以部署在一台可以访问的内网服务器上员工居家时通过内部网络通道接入。关于HTTPS如果申请了域名建议顺手配一下免费的HTTPS证书。不配的话文件传输的用户名密码、文档内容都以明文形式在网络上传输在居家网络环境复杂的情况下风险很高。证书配置只需要在Nginx里增加几行ssl配置成本很低收益很大。7.4 安全加固与性能优化的建议系统上线前我把安全相关的问题梳理一遍几个重点如下密码安全Django默认的PBKDF2算法不需要额外处理前提是不要自己写加密逻辑。文件上传安全后端校验扩展名和文件大小只做了一层更高要求的项目可以增加MIME类型校验和内容头校验甚至做文件内容扫描。访问控制API接口全部通过JWT认证没有写permission_classes [AllowAny]的接口。数据库备份部署服务器上配置了crontab每天凌晨备份SQLite/MySQL数据库到备份目录保留最近7天。文档系统的数据价值就在数据库里备份不能省。性能优化方面眼下这套架构还没到需要上缓存、上消息队列的阶段。如果非要提前优化我会建议在后端给文档列表接口加上select_related和prefetch_related减少N1查询以及在图片预览时按需压缩。最后再分享一个我做这类项目的心得。很多同学拿到XX系统的设计与实现这种题目时容易一上来就撸代码结果做到一半发现逻辑混乱、表结构改来改去。我这次是先花了两天时间把需求、表结构、接口清单、页面草图全部过了一遍代码阶段反而很顺利。文档管理系统这种东西业务逻辑不算难真正的价值在于把每个细节想清楚——比如版本回滚的策略、权限边界、文件存储的路径规则、异常情况的处理。把这些想透了代码写得快后期维护也不容易出幺蛾子。如果正在照着这个题目做我的建议是先画一张包含角色-功能-数据表-接口四层关系的脑图再动手写第一行代码整个过程能顺畅很多。 基于Python+Vue的居家办公文档管理系统设计与实现
从居家办公成为企业常态那一天起文档管理就不再是把文件存进共享文件夹这么简单了。团队分散在各家各户一个项目方案从初稿到终稿往往要经历七八次修改最终版本散落在不同人的电脑里主管想审批一份报告得在微信聊天记录里爬楼新同事入职连项目文档在哪找都不知道。我做这个pythonVUE企业员工居家在线办公文档管理系统的设计与实现项目就是为了把文档的采集、存储、版本、权限、归档这一整条链路理顺。本文会按照项目的实际推进顺序从需求拆解到技术选型从数据库设计到前后端实现再到联调和部署把完整的思路和关键代码逻辑完整整理出来。想拿这个题目做毕业设计或者计划给团队搭一套内部文档系统的开发同学可以直接参考这套落地路径。1. 居家办公场景下文档管理到底要管什么1.1 先理解居家办公和坐在办公室里管理文档的差异做这个系统之前我先把传统办公和居家办公的文档使用场景做了个对比。道理很简单使用场景变了系统设计的前提就不一样。在办公室场景中文件传输主要靠U盘拷贝和共享文件夹网络环境稳定同事之间的沟通链路短。一旦转到居家办公立刻出现几个新问题一是员工之间物理隔离文件只能走线上传输但线上传输工具的版本管理能力几乎为零微信传文件传到最后经常出现最终版v2(1).docx这种命名惨案二是文档的权限边界变得模糊很多敏感文件在没有控制的渠道里流转出问题根本追溯不到源头三是不在同一个办公网时员工需要从外部访问企业内网的文档资源这对系统的网络访问方式提出了要求。所以这个系统在设计之初就没有简单定成一个文件上传和下载的工具而是奔着让文档像在企业内网一样有序流转去做的。核心要解决的三个问题是文档存得下可靠的存储、找得到分类和搜索、用不滥权限和日志。1.2 角色和功能模块怎么拆我把系统的使用者拆成了三个角色普通员工、部门主管、系统管理员。三个角色的权限不同界面呈现的重点也不同。普通员工上传文档、下载文档、维护自己上传的文档、查看操作记录。部门主管拥有普通员工全部权限还能查看本部门的文档库、浏览部门内员工的上传记录、对文档进行归档或下架处理。系统管理员用户管理、分类管理、全库文档管理、操作日志审计、系统参数配置。围绕这三个角色功能模块可以拆成下面这张表功能模块子功能说明用户认证登录、登出、密码修改JWT无状态认证支持跨域调用文档管理上传、下载、删除、修改支持单文档多版本分类管理多级分类、分类维护如行政类、技术类、人事类版本管理新增版本、版本列表、版本回滚保留历史快照可追溯搜索筛选关键字搜索、分类筛选、时间排序提升大量文档下的查找效率操作日志记录关键操作、审计查询谁在什么时间做了什么操作权限控制基于角色的权限隔离员工只能操作自己有权限的文档这套模块拆完之后系统的边界就清楚了。没有做在线编辑功能也没有做复杂的工作流审批因为文档管理和文档协作是两个量级的产品在设计与实现这个规模下把存储、版本、权限、日志做扎实就已经能覆盖居家办公的核心痛点。1.3 提前约定非功能需求除了功能需求我在动手前还给自己定了几条非功能约束这些约束直接影响技术选型和数据库设计。文件上传大小单文件上限设定为100MB。居家办公环境下大文件如设计稿、录屏视频也比较常见。并发要求按中小型团队设计预计同时在线人数50人以内避免过度设计。安全要求密码存储必须加密、上传文件必须校验类型、操作必须留痕。部署环境考虑到成本计划部署在一台2核4G的云服务器上因此前后端要分离部署、静态文件要交给Nginx托管。这些约束让后续的每一步选择都变得有据可依不会为了炫技引入不必要的复杂度。2. 技术栈落地为什么是Django Vue3而不是Flask Vue2说实话一开始我也在Flask和Django之间犹豫过。网上Python后端框架的对比文章一大把但真正落到自己的项目里核心判断维度就那么几个开发效率、内置功能、生态成熟度、调试方便程度。2.1 后端选Django的理由对于文档管理系统这种典型的管理信息系统Flask确实能写而且写起来很自由。但自由是有代价的数据库迁移要自己配、Admin后台要自己搭、用户认证要自己画、ORM要自己挑。一堆决策做完可能还没开始写业务代码。Django的优势在于官方已内置。Django自带的ORM、Admin后台、User认证体系、表单校验、中间件机制几乎就是为管理类系统量身定做的。尤其是Admin后台在开发阶段可以直接用它来管理用户、查看数据调试效率极高。最终选定的版本组合是Python 3.10 Django 4.2 Django REST Framework SimpleJWT。Django 4.2是当前比较稳定的版本DRF负责把MVT转换成更符合前后端分离习惯的API接口SimpleJWT用来提供无状态的Token认证。这个组合在社区里非常成熟遇到问题基本都能搜到解法这一点对做毕业设计或新手项目来说非常重要。2.2 前端选Vue3的理由前端框架没什么悬念选Vue 3。热词里大量出现vue安装及环境配置vue路由vue computed说明Vue生态的入门资料已经足够丰富真要遇到Vue3的语法细节问题文档和社区都能兜底。Vue 3正式版发布以来组合式APIComposition API带来的代码组织方式改进非常明显。对文档管理这种以页面为核心的中后台项目用组合式API可以把某个业务功能的响应式数据、计算属性、方法函数聚在一起逻辑更清晰。再搭配上Vite作为构建工具开发环境的启动速度比Webpack快了不只一个档次。UI组件库选了Element Plus。这是Vue 3生态里最成熟的桌面端组件库表格、上传、分页、对话框这些后台管理系统的常客都有现成组件能省掉大量手写样式的时间。2.3 前后端分离的架构约定整个项目采用前后端分离架构前端是独立的Vue应用通过HTTP请求调用后端API。后端只负责提供JSON数据接口前端只负责渲染页面和交互两者通过接口文档进行契约约定。为了让接口风格统一我简单的设计如下约定接口统一前缀/api/数据返回格式统一为{code: 200, message: success, data: {...}}文件上传使用multipart/form-data格式提交文件下载使用二进制流返回前端按blob处理这套约定在后端写API的时候就要严格遵守不然前后端联调阶段会有吐不完的槽。3. 数据库设计五张核心表如何覆盖文档全生命周期3.1 实体关系梳理文档管理系统的核心数据实体我梳理出来是五张表用户表、分类表、文档表、版本表、操作日志表。用户和文档是一对多关系一个用户上传多份文档文档和版本是一对多关系一份文档可以有多个历史版本文档和分类是多对一关系一份文档归属一个分类用户和操作日志是一对多关系一个用户产生多条日志。关系理清楚之后表结构的设计就水到渠成了。3.2 核心表结构用户表直接继承Django自带的AbstractUser在原有字段基础上扩展了部门、角色等业务字段没有自己从零建既省事又安全。字段类型说明idint主键usernamevarchar用户名唯一passwordvarchar密文存储departmentvarchar所属部门rolevarchar角色admin / manager / staffphonevarchar手机号is_activebool是否启用文档分类表支持多级分类用parent_id自关联。字段类型说明idint主键namevarchar分类名称parent_idint父级分类ID0为顶级sort_orderint排序权重create_timedatetime创建时间文档表是整个系统的核心。字段类型说明idint主键titlevarchar文档标题descriptiontext文档描述file_pathvarchar文件存储路径file_typevarchar文件类型file_sizebigint文件大小字节categoryint外键所属分类uploaderint外键上传者current_versionvarchar当前版本号statusvarchar状态draft / published / archiveddownload_countint下载次数create_timedatetime创建时间update_timedatetime更新时间版本表记录文档的每一次变更。字段类型说明idint主键documentint外键所属文档version_numvarchar版本号file_pathvarchar该版本文件路径change_notetext更新说明create_timedatetime创建时间uploaderint外键上传人操作日志表做最简单的流水记录。字段类型说明idint主键userint外键操作人actionvarchar操作类型doc_idint文档IDdetailvarchar操作详情ip_addressvarchar操作IPcreate_timedatetime操作时间3.3 为什么文档和版本一定分表这是设计阶段比较重要的一张判断。很多第一次做文档系统的人会把文件直接替换成一份新的旧文件覆盖掉这样做最简单但会让系统失去追溯能力。版本管理是这个系统的核心价值之一如果员工上传了一份错误的文件管理员要把系统里已上传的错误文件找回来版本回滚是唯一能救命的方案。所以我坚持把文档本身和它的历史版本分成两张表。文档表存的是当前状态版本表存的是历史快照。当用户上传新版本时逻辑上是这样的文档表里的file_path和current_version更新到新文件旧文件的路径和元数据则插入到版本表中。这样既能保证文档列表查询的高效又能完整保留每一次变更痕迹。后面的接口代码里会再细说这个逻辑。4. 后端实现上传、下载、版本、权限四条主线的关键代码4.1 项目初始化Django项目的骨架初始化是很标准的操作。创建虚拟环境、安装依赖、django-admin startproject、python manage.py startapp docs、startapp users、startapp logs按模块拆分成三个应用职责边界清晰。关键依赖写入requirements.txtDjango4.2 djangorestframework3.14 djangorestframework-simplejwt5.2 django-cors-headers4.0 Pillow10.0在settings.py里需要做几处关键配置把rest_framework、corsheaders、docs、users、logs注册进INSTALLED_APPS配置DRF的默认认证类为JWT配置媒体文件的保存路径。文件上传会保存到media目录下MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media4.2 模型定义了系统的地基文档模型的关键字段设计我按照前面数据库设计部分的表格来实现。需要注意的一个细节是file_path字段存的是相对路径而非绝对路径这样部署在不同环境时只需要修改MEDIA_ROOT配置不必动数据库里的数据。from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): DEPARTMENT_CHOICES [ (tech, 技术部), (hr, 人事部), (finance, 财务部), (admin, 行政部), ] ROLE_CHOICES [ (staff, 员工), (manager, 主管), (admin, 管理员), ] department models.CharField(max_length50, choicesDEPARTMENT_CHOICES, blankTrue) role models.CharField(max_length20, choicesROLE_CHOICES, defaultstaff) phone models.CharField(max_length20, blankTrue) class DocCategory(models.Model): name models.CharField(max_length100) parent models.ForeignKey(self, nullTrue, blankTrue, on_deletemodels.CASCADE) sort_order models.IntegerField(default0) create_time models.DateTimeField(auto_now_addTrue) class Document(models.Model): STATUS_CHOICES [ (draft, 草稿), (published, 已发布), (archived, 已归档), ] title models.CharField(max_length200) description models.TextField(blankTrue) file models.FileField(upload_todocuments/%Y/%m/) file_type models.CharField(max_length50, blankTrue) file_size models.BigIntegerField(default0) category models.ForeignKey(DocCategory, on_deletemodels.SET_NULL, nullTrue) uploader models.ForeignKey(User, on_deletemodels.CASCADE, related_namedocuments) current_version models.CharField(max_length20, defaultv1) status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultdraft) download_count models.IntegerField(default0) create_time models.DateTimeField(auto_now_addTrue) update_time models.DateTimeField(auto_nowTrue) class DocumentVersion(models.Model): document models.ForeignKey(Document, on_deletemodels.CASCADE, related_nameversions) version_num models.CharField(max_length20) file models.FileField(upload_todocuments/versions/%Y/%m/) change_note models.TextField(blankTrue) uploader models.ForeignKey(User, on_deletemodels.SET_NULL, nullTrue) create_time models.DateTimeField(auto_now_addTrue) class OperationLog(models.Model): user models.ForeignKey(User, on_deletemodels.SET_NULL, nullTrue) action models.CharField(max_length50) doc_id models.IntegerField(nullTrue, blankTrue) detail models.CharField(max_length500, blankTrue) ip_address models.GenericIPAddressField(nullTrue) create_time models.DateTimeField(auto_now_addTrue)FileField是Django处理文件上传的核心。它会把文件写入MEDIA_ROOT对应的目录并把相对路径保存到数据库字段里。upload_to参数里加了%Y/%m/文件会自动按年和月归档到不同子目录避免一个目录下文件过多。4.3 上传接口的逻辑链DRF中写上传接口最常规的设计是序列化器配合通用视图。上传接口的核心逻辑不只是把文件存下来还包括校验文件类型、限制文件大小、识别文件类型然后才保存记录。时间关系接口代码用函数视图演示会更清晰from rest_framework.decorators import api_view, permission_classes from rest_framework.permissions import IsAuthenticated from django.core.exceptions import ValidationError ALLOWED_EXTENSIONS [pdf, doc, docx, xls, xlsx, ppt, pptx, txt, png, jpg, jpeg, zip] MAX_FILE_SIZE 100 * 1024 * 1024 # 100MB api_view([POST]) permission_classes([IsAuthenticated]) def upload_document(request): file request.FILES.get(file) title request.data.get(title, ) category_id request.data.get(category_id, None) if not file: return Response({code: 400, message: 未上传文件}, status400) ext file.name.split(.)[-1].lower() if ext not in ALLOWED_EXTENSIONS: return Response({code: 400, message: 不支持的文件类型}, status400) if file.size MAX_FILE_SIZE: return Response({code: 400, message: 文件大小超出限制}, status400) doc Document.objects.create( titletitle or file.name, filefile, file_typeext, file_sizefile.size, uploaderrequest.user, category_idcategory_id, current_versionv1 ) OperationLog.objects.create( userrequest.user, actionupload, doc_iddoc.id, detailf上传文档{doc.title}, ip_addressrequest.META.get(REMOTE_ADDR) ) return Response({code: 200, message: 上传成功, data: {doc_id: doc.id}})文件类型校验这一层不能省。虽然前端也做了限制但恶意请求完全能绕过前端直接打到后端接口后端不校验就等于裸奔。下载接口要考虑的细节是download_count的递增。为了性能这个字段不需要强一致每次下载加一即可不会对系统正确性造成影响。4.4 版本管理的核心新增与回滚新增版本的逻辑可以概括为三步把文档表当前的file数据快照到版本表、把文档表的file和current_version更新为新文件、在版本表插入一条新版本记录。具体实现时有一个先后顺序问题很重要一定要先把旧文件信息保存到版本表然后再覆盖文档表的文件字段顺序搞反就会丢失历史数据。api_view([POST]) permission_classes([IsAuthenticated]) def add_version(request, doc_id): doc Document.objects.get(iddoc_id) # 校验当前用户是否有操作权限略 file request.FILES.get(file) if not file: return Response({code: 400, message: 未上传文件}, status400) # 旧版本快照 DocumentVersion.objects.create( documentdoc, version_numdoc.current_version, filedoc.file, change_noterequest.data.get(change_note, ), uploaderrequest.user ) # 更新文档主表 version_num v str(len(doc.versions.all()) 1) doc.file file doc.current_version version_num doc.file_size file.size doc.file_type file.name.split(.)[-1].lower() doc.save() return Response({code: 200, message: 版本更新成功, data: {version_num: version_num}})版本回滚逻辑刚好相反从版本表里取回指定版本的记录把它还原成一个新版本写入当前文档同时保留当前版本作为快照。这里我采用的是回滚即产生新版本的策略而不是简单地把字段覆盖回去这样每次操作都有完整记录符合审计要求。权限校验我用的是自定义装饰器。最基础的代码思路是def role_required(allowed_roles): def decorator(view_func): wraps(view_func) def _wrapped_view(request, *args, **kwargs): if request.user.role not in allowed_roles: return Response({code: 403, message: 没有权限执行该操作}, status403) return view_func(request, *args, **kwargs) return _wrapped_view return decorator对于员工文档删除这类操作还需要额外的属主校验普通员工只能操作自己上传的文档主管可以操作本部门所有文档管理员可以操作所有文档。没有这套控制居家办公场景下的权限混乱问题根本没解决。5. 前端实现Vue3 Element Plus搭出可用的文档管理台5.1 工程初始化与目录规划前端工程我用Vite搭建。执行npm create vuelatest按提示选择Vue Router、Pinia、ESLint等选项。项目目录按模块组织没有用默认的views一锅端而是按业务维度划分src/ ├── api/ # 接口请求封装 │ ├── auth.js │ └── document.js ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── stores/ # Pinia状态管理 ├── views/ # 页面组件 │ ├── LoginView.vue │ ├── HomeView.vue │ ├── DocumentListView.vue │ ├── DocumentDetailView.vue │ ├── VersionListView.vue │ └── LogView.vue ├── utils/ # 工具函数 └── main.jsapi/目录把接口调用单独封装页面组件里不直接写请求地址这是一个值得坚持的小习惯。后面前端组件只调用import { getDocList } from /api/document可读性和可维护性都高很多。5.2 路由与状态管理路由配置需要区分角色未登录用户只能访问登录页管理员和普通员工能访问的菜单不同。简单的做法是在路由配置文件里加一个meta字段来标记所需权限然后在router.beforeEach守卫里做判断。const routes [ { path: /login, component: LoginView }, { path: /documents, component: DocumentListView, meta: { requiresAuth: true } }, { path: /logs, component: LogView, meta: { requiresAuth: true, roles: [admin] } } ] router.beforeEach((to, from, next) { const token localStorage.getItem(access_token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })用户状态用Pinia来管理。登录成功之后把用户信息和Token写入store页面刷新的时候再从localStorage恢复。Token的存取参考了业界惯例access_token有效期短2小时refresh_token有效期长7天前端请求拦截器在遇到401时尝试刷新Token刷新成功就重放原请求。5.3 文档列表页的核心交互文档列表页是这个系统前端的关键页面。Element Plus的el-table组件负责表格渲染el-pagination负责分页。上传功能我用el-upload组件实现。一个容易踩坑的细节是el-upload和自定义后端接口对接时不要把文件交给组件内部的action自动上传而是设置http-request自定义上传函数把文件交给我们的axios实例处理这样Token才能正确注入到请求头。el-upload :show-file-listfalse :http-requesthandleUpload accept.pdf,.doc,.docx,.xls,.xlsx el-button typeprimary上传文档/el-button /el-upload script setup const handleUpload async (options) { const formData new FormData() formData.append(file, options.file) formData.append(title, titleRef.value) formData.append(category_id, categoryIdRef.value) const res await uploadDocument(formData) if (res.data.code 200) { ElMessage.success(上传成功) fetchList() } } /script列表页的数据加载逻辑不算复杂但是要处理好加载状态、数据刷新、以及列表项里的操作按钮权限控制。普通员工进入页面时文档列表只显示自己可见的文档主管可以切换部门筛选管理员能看到全局数据。这些权限状态在Pinia里维护视图里通过v-if判断避免权限泄露。5.4 下载与预览的交互处理文件下载在前端不能直接用一个a标签跳转因为后端接口需要Token认证直接跳转会把Token丢失。正确的做法是用axios设置responseType: blob拿到二进制流后用URL.createObjectURL生成临时链接再触发下载。这个过程有一个我调了很久的坑后端返回的文件名如果带中文直接放在Content-Disposition头里会被浏览器识别成乱码需要在前端解析文件名时做一次decode处理。在线预览功能我只实现了图片、[纯文本]、PDF三类视频和Office文件预览依赖Office Online服务受限于服务稳定性并没有集成。图片预览直接打开el-image的预览模式文本和PDF则通过iframe加载blob URL实现简单但够用。6. 前后端联调跨域、Token、文件流三个必踩的坑6.1 跨域问题的根源与配置开发环境下前端跑在5173端口后端跑在8000端口不同源跨域问题第一轮联调就出现了。前端的控制台直接报错CORS policy: No Access-Control-Allow-Origin header is present。这个问题的解决很简单后端安装django-cors-headers在settings.py中配置允许的源。INSTALLED_APPS [ ... corsheaders, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://127.0.0.1:5173, ]需要注意CorsMiddleware要放在CommonMiddleware之前才能正常工作。开发环境只允许本地地址生产环境要换成服务器的域名或IP不要把CORS_ALLOW_ALL_ORIGINSTrue带到生产环境。6.2 Token注入与401刷新axios请求拦截器里统一注入Token这是最常见的做法service.interceptors.request.use(config { const token localStorage.getItem(access_token) if (token) { config.headers.Authorization Bearer ${token} } return config })响应拦截器中需要处理两个问题一是Token过期时返回401自动调用刷新接口二是业务层面的错误码处理。当时我遇到一个很隐蔽的问题JWT的刷新接口在Token过期后第一次调用就报错排查出来是SimpleJWT默认的刷新令牌有效期是24小时而我设置的过期时间超过了这个值。后来统一把刷新令牌有效期调成7天并且前端把refresh_token和access_token分开存储。6.3 文件流下载的中文文件名文件下载时遇到的编码问题是联调阶段最耗时的一个。我的后端代码设置了Content-Disposition: attachment; filenamexxx.pdf但如果是中文文件名浏览器收到的头会被RFC 5987编码规则限制。解决办法是后端使用quote对文件名做编码同时生成一个filename*字段前端在解析时也要做对应处理。from urllib.parse import quote filename 项目方案终稿.pdf disposition fattachment; filename*UTF-8{quote(filename)} response[Content-Disposition] disposition这个坑很典型单看后端接口返回正确单看前端逻辑正确但从浏览器角度验证就是乱码。联调阶段一定要用浏览器开发者工具直接观察响应头别只盯着Network里的状态码和响应体。6.4 大文件上传100MB以内的文件直接走普通的multipart上传问题不大。但实测过程中发现公司里设计部门的PSD文件往往能到几百MB甚至1GB超过限制用户就会投诉。考虑到这个项目定位是中小型团队内部系统我把单文件限制调到了500MB并增加了分片上传的后续优化方案。分片上传的思路其实不复杂前端把文件按固定大小比如5MB切片逐片上传后端记录每个切片的状态全部上传完成后触发合并。切片上传的好处是支持断点续传网络中断后不用重新上传整个文件。但完整做下来要配合后端增加合并文件接口、设计切片编号、处理并发顺序工作量并不小。我在当前的毕业设计版本里保留了普通上传方案分片上传作为后续优化方向在系统设计文档中做了说明。7. 部署到服务器居家办公场景下的远程访问方案7.1 后端部署后端部署我选的是Gunicorn作为WSGI服务器。先在服务器上创建虚拟环境安装依赖做数据库迁移然后启动Gunicorn监听127.0.0.1:8000端口。cd /opt/doc_system/backend source venv/bin/activate pip install -r requirements.txt python manage.py migrate python manage.py collectstatic --noinput gunicorn config.wsgi:application -b 127.0.0.1:8000 -w 4 --timeout 60-w 4表示4个worker进程一台2核4G服务器跑这个配置并发扛几十个用户够用。--timeout 60是因为文件上传接口有时超过默认的30秒需要延长超时时间否则大文件上传容易超时被杀。7.2 前端构建与Nginx反向代理前端构建生成静态文件上传到服务器的/opt/doc_system/frontend目录。Nginx负责两件事一是托管前端静态文件二是把/api/的请求反向代理到后端Gunicorn进程。server { listen 80; server_name your-domain.com; # 前端静态文件 root /opt/doc_system/frontend; index index.html; # 历史路由支持Vue Router启用history模式需要 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 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; proxy_read_timeout 300s; } # 上传文件访问 location /media/ { alias /opt/doc_system/backend/media/; } }location /中的try_files配置是Vue Router使用history模式时的刚需没有它刷新页面就会404。手动测一下能绕开这个问题。7.3 居家远程访问云服务器是首选方案居家办公环境下员工需要从外部网络访问内部系统访问方案在设计之初就要想清楚。我的建议是把系统部署到一台具有公网IP的云服务器上员工通过域名或公网IP访问。这是最稳定也最干净的方式。如果团队预算有限也可以部署在一台可以访问的内网服务器上员工居家时通过内部网络通道接入。关于HTTPS如果申请了域名建议顺手配一下免费的HTTPS证书。不配的话文件传输的用户名密码、文档内容都以明文形式在网络上传输在居家网络环境复杂的情况下风险很高。证书配置只需要在Nginx里增加几行ssl配置成本很低收益很大。7.4 安全加固与性能优化的建议系统上线前我把安全相关的问题梳理一遍几个重点如下密码安全Django默认的PBKDF2算法不需要额外处理前提是不要自己写加密逻辑。文件上传安全后端校验扩展名和文件大小只做了一层更高要求的项目可以增加MIME类型校验和内容头校验甚至做文件内容扫描。访问控制API接口全部通过JWT认证没有写permission_classes [AllowAny]的接口。数据库备份部署服务器上配置了crontab每天凌晨备份SQLite/MySQL数据库到备份目录保留最近7天。文档系统的数据价值就在数据库里备份不能省。性能优化方面眼下这套架构还没到需要上缓存、上消息队列的阶段。如果非要提前优化我会建议在后端给文档列表接口加上select_related和prefetch_related减少N1查询以及在图片预览时按需压缩。最后再分享一个我做这类项目的心得。很多同学拿到XX系统的设计与实现这种题目时容易一上来就撸代码结果做到一半发现逻辑混乱、表结构改来改去。我这次是先花了两天时间把需求、表结构、接口清单、页面草图全部过了一遍代码阶段反而很顺利。文档管理系统这种东西业务逻辑不算难真正的价值在于把每个细节想清楚——比如版本回滚的策略、权限边界、文件存储的路径规则、异常情况的处理。把这些想透了代码写得快后期维护也不容易出幺蛾子。如果正在照着这个题目做我的建议是先画一张包含角色-功能-数据表-接口四层关系的脑图再动手写第一行代码整个过程能顺畅很多。