我去年年初接手了一个内部审批流程改造项目，需求很直白：把纸质审批单、人工跑签、月度归档这套流程彻底搬到线上。团队当时就三个人，后端熟 Python，前端没有专职，但 Vue 从生态到学习曲线都是最稳妥的选择，于是定了 Python + Vue 这套组合，后端框架在 Django 和 Flask 之间纠结了两天。这个场景放在今天来看，几乎是中小团队和内部系统最典型的选型路径。这篇文章就围绕这个项目标题展开，结合我在实际开发中用 PyCharm 搭建的整个工程，把无纸化办公系统的模块设计、后端接口实现、前端工程搭建，以及前后端联调时踩过的坑完整梳理一遍。
1. 无纸化办公系统的骨架：整体设计与模块拆解
先说结论：无纸化办公系统本质上是“业务流转 + 数据归档”的数字化平台，把原本依赖物理单据的流程变成线上数据流。无论用哪种框架组合，系统的骨架都离不开几个核心模块，它们决定了系统能不能真正落地。
1.1 核心需求解析
标题里“无纸化办公”这个关键词背后，最常见的真实业务诉求分四层：
- 流程审批：报销、请假、用章、采购申请，这些高频场景是上线第一批功能。特点是流程固定、节点明确，适合先做。
- 权限与身份：系统要区分管理员、部门负责人、普通员工，不同人看到的菜单、可操作的按钮都不一样。
- 文件与归档：审批通过后的单据要能导出、可检索，替代纸质档案柜。
- 数据统计：各部分的审批量、平均审批时长、超时件数，管理者需要看到这些指标。
我接触过不少类似项目，最容易翻车的问题就是贪大求全，一上来就想做公告、日程、会议室预约、内部论坛一大堆。实际开发中正确的切入策略是“先跑通一条主流程，再横向扩展”。我们的首个版本只做了请假审批这一条链路：员工提交申请，直属领导审批，行政归档，月度导出。这条链路跑通后，加报销、加用章申请就是复制模板的事。
1.2 系统架构与模块划分
整体架构分为三层：Vue 前端负责交互和展示，RESTful API 作为前后端通信桥梁，后端负责业务逻辑和数据库读写。
模块划分建议按业务域拆分，而不是按技术职责拆分：
- 认证模块：登录、令牌刷新、密码修改。
- 流程引擎模块：审批流的模板定义、实例生成、节点流转。
- 业务单据模块：请假单、报销单、用章单的数据结构。
- 文件模块：附件上传、导出归档。
- 统计模块：按部门、按类型汇总审批数据。
前四个模块是第一个版本必须完成的。统计模块可以放在第二期，甚至先用 SQL 手工查询顶一阵，优先级不需要那么高。
1.3 为什么选前后端分离而不是模板引擎
现在的无纸化办公系统，除非是纯内部几十人用的小工具，我强烈建议不要用 Django 自带的模板系统直接渲染页面。原因很现实：
- 交互复杂度：审批流程涉及动态表单、级联选择、分步操作，前后端分离的组件化开发效率明显更高。
- 复用需求：系统后续大概率要做移动端适配。Vue 的 SPA 可以直接嵌套 WebView，或者用 uni-app 适配多端，后端接口不用改一行代码。
- 团队协作：前后端分离后，前端 mock 数据就能开发，不需要等后端接口写完，并行开发效率高很多。
当然，这也意味着你要额外处理跨域、Token 存储、打包部署这些问题。这些坑本文后面都会讲到，提前了解可以少走很多弯路。
2. 后端框架二选一：Django 还是 Flask
标题里同时出现了 django 和 flask，很多初学者会误以为要同时用两个框架，其实不是。这是“二选一”的关系。我在这个项目里调研时的对比结论如下，因为项目周期紧、团队没有专职前端，最终选了 Flask，但如果你遇到的情况不同，结论可能相反。
2.1 两组框架的定位差异
从哲学上讲，两者是完全不同的思路。Django 是“全家桶”，内置了 ORM、Admin 后台、表单验证、认证体系、中间件，甚至有自带的模板引擎和静态文件处理。你用它，相当于直接开一辆配置齐全的车，大部分常用零件都帮你装好了，约定大于配置，项目结构相对固定。
Flask 则非常小而美，核心只做路由和请求响应，其他能力全靠扩展包。你把 Flask 理解成一台可以自己组装的车更贴切，选哪些零件、怎么布局，完全由你决定，灵活性极高，但也意味着你要自己做出更多的决策。
2.2 选型背后三个决定性因素
- 团队技能基线：如果团队成员之前有过 Django 的 MTV 开发经验，强烈建议沿用 Django，因为经验可以直接迁移。反过来，如果团队更熟悉 Flask 或微型框架，不要强行上 Django。项目能不能按时交付，团队是否熟练比框架本身更重要。
- 项目规模和可维护性：无纸化办公系统若定位为长期演进的公司级平台，后续会加入组织架构管理、消息推送、定时任务等，Django 的生态会给维护省很多事。如果只是部门级工具，Flask + 几个扩展包够了，轻量且易读。
- 数据模型复杂度：Django 的 ORM 非常强大，关联查询、数据迁移、Admin 生成，在模型复杂时效率极高。Flask 需要搭配 SQLAlchemy 才能达到类似体验，配置多了一层。
2.3 最终选型建议
我的实际建议是：50 人以下、审批链路较少、团队兼职维护，选 Flask；体系化公司级办公平台，团队有一定后端规模，选 Django。技术上没有谁碾压谁，只有谁更适合你的场景。
两种框架现在都支持 ASGI 异步，但异步不是无纸化系统的核心需求。审批流程写库是轻量的，异步最容易出杂七杂八的问题。同步模型加上适当缓存，已经足够应对几百人规模的并发量。
3. 从模型到接口：后端核心模块设计与实现
选定框架后，最核心的设计工作就是数据模型和接口。后端这层设计得好不好，直接影响前端开发效率和后续维护成本。
3.1 数据库选择：SQLite 还是 MySQL
内部无纸化办公系统，并发规模通常不大。我们的项目起步直接用 SQLite，文件型数据库，零配置，一个文件就能跑起来，对开发调试太友好了。团队开发时每个人本地复制一份或直接用同一个文件，数据同步也简单。
但生产环境如果公司已有 MySQL 实例，建议直接连 MySQL，因为后续大概率会有多服务器部署需求，SQLite 不支持网络访问，这是硬伤。开发环境用 SQLite、生产环境用 MySQL，是一个性价比很高的策略。Django 改配置切换数据库，Flask 配 SQLAlchemy 也是换连接串的事，注意避免使用数据库特有语法。
3.2 数据表规划与 ORM 建模要点
无纸化系统的核心数据表大致如下：
- user 表：账号、密码哈希、姓名、部门、角色。
- department 表：部门名称、上级部门、负责人。
- approval_template 表：审批流模板，包含流程的节点顺序定义。
- leave_form 表：请假单数据，关联提交人、审批人、当前状态。
- approval_record 表：审批实例的流转记录，每一步的审批人和结果。
- attachment 表：附件元信息，关联单据 ID。
关键设计心得在于“模板与实例分离”：审批模板（比如请假流程）是静态定义，每次提交申请则创建一个独立的审批实例。这样如果后续调整了流程模板，历史单据不会受牵连。
以下是 Flask + SQLAlchemy 的模型片段，比 Django 的 models.py 更灵活，更适合团队现场按需调整：
from flask_sqlalchemy import SQLAlchemy from datetime import datetime db = SQLAlchemy() class Department(db.Model): __tablename__ = 'department' id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(64), unique=True, nullable=False) parent_id = db.Column(db.Integer, db.ForeignKey('department.id')) class User(db.Model): __tablename__ = 'user' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False) password_hash = db.Column(db.String(256), nullable=False) department_id = db.Column(db.Integer, db.ForeignKey('department.id')) role = db.Column(db.String(16), default='employee') class LeaveForm(db.Model): __tablename__ = 'leave_form' id = db.Column(db.Integer, primary_key=True) applicant_id = db.Column(db.Integer, db.ForeignKey('user.id')) leave_type = db.Column(db.String(32), nullable=False) start_date = db.Column(db.Date, nullable=False) end_date = db.Column(db.Date, nullable=False) reason = db.Column(db.Text, nullable=False) status = db.Column(db.String(16), default='pending') created_at = db.Column(db.DateTime, default=datetime.now)注意密码字段永远不存明文，用哈希。Python 比较方便的做法是hashlib.pbkdf2_hmac或者直接用 Werkzeug 自带的密码哈希函数。
3.3 登录认证与 JWT 流程
无纸化办公系统是前后端分离架构，Session 方案存在跨域和移动端不友好的问题。最终选了 JWT，一个本地无状态 Token，服务器不用保存额外记录，扩展性好。
JWT 的工作流程可以类比门禁手环：你买票进场时，服务台核实你的身份后给你一个带签名的手环，这里面写了你是谁、什么时候到期。之后你去每个游戏区，工作人员只看手环，不再向服务台确认身份。手环上有防伪签名，工作人员可以验明真伪；你自己改手环信息会破坏签名，立刻被发现。
后端实现一般为两个接口：登录接口校验用户名密码，返回 Access Token；后续所有业务接口读请求头里的 Authorization 字段，验证 Token 后提取用户身份。
Flask 中可以这样组织：
import jwt from functools import wraps from flask import request, jsonify SECRET_KEY = 'your-secret-key' def generate_token(user_id): payload = { 'user_id': user_id, 'exp': datetime.utcnow() + timedelta(hours=12) } return jwt.encode(payload, SECRET_KEY, algorithm='HS256') def login_required(f): @wraps(f) def wrapper(*args, **kwargs): token = request.headers.get('Authorization', '').replace('Bearer ', '') try: payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256']) request.user_id = payload['user_id'] except jwt.ExpiredSignatureError: return jsonify({'code': 401, 'msg': '登录已过期'}), 401 except jwt.InvalidTokenError: return jsonify({'code': 401, 'msg': '无效令牌'}), 401 return f(*args, **kwargs) return wrapper这个方案里 SECRET_KEY 的管理是重点。不要硬编码丢在代码仓库里，我通常会放在环境变量或单独的配置文件，加入 gitignore。密钥泄露的后果是任何人都能伪造 Token，权限体系形同虚设。
3.4 RBAC 权限控制：控制到接口和按钮
RBAC 是最成熟且最匹配当前场景的权限模型。三张表：用户、角色、权限，中间用用户-角色、角色-权限两张关联表衔接。
一个员工登录进来，他能看到什么菜单、能点哪个按钮、能调哪个接口，全部由角色权限决定。例如“审批”菜单只对部门负责人和管理员角色可见，请假超过三天的单子需要总经理角色才能终审。
Django 自带权限框架和 Admin 界面，RBAC 上手快；Flask 则需要自己实现这个模型。权限颗粒度到“页面可见”或“按钮可点”级别即可，这个系统暂时不需要做到数据行级权限那么细。
3.5 审批流核心设计：状态机与节点跳转
审批流是无纸化系统的价值中枢，很多框架里爱用现成的第三方流程引擎，但前期我建议自己写一个精简版。原因很简单：内部审批流程的逻辑不算复杂，自己写对业务的适配度反而更高，出问题排查也方便。
核心逻辑是状态机。以请假为例，状态从pending开始，审批通过进入approved，拒绝跳到rejected，还可以有cancelled状态。每个状态之间有哪些合法转移，提前在代码里定义清楚，防止状态混乱。
比布尔式的“通过/拒绝”更合理的设计是节点流转。创建approval_template表存放节点顺序，例如[direct_manager_approval, hr_confirmation]。提交申请时，按模板生成一个审批实例，包含一个步进指针。当前节点审批完成，指针加一，直到走到终点状态。
这里有个在开发中很容易踩的坑：并发提交问题。同一个单子两个人同时审批，可能出现数据覆盖。解法是为审批记录加乐观锁版本号，更新时校验版本号一致才允许写入。系统里可以简单加一个version字段。
3.6 表单引擎思想：动态字段的一种简版实现
真实的办公系统里，请假和报销的表单字段完全不同。如果给每种表单写死前端组件，代码会爆发式增长。这需要引入表单引擎思想，简单来就是让后端把表单结构定义传给前端，前端动态渲染。
实现上，把表单字段定义存成 JSON：
{ "fields": [ {"name": "leave_type", "label": "请假类型", "type": "select", "options": ["事假", "病假", "年假"]}, {"name": "start_date", "label": "开始日期", "type": "date"}, {"name": "reason", "label": "请假事由", "type": "textarea"} ] }前端拿这个 JSON 动态生成表单。新增一种单据类型时，只需要改后端配置，不需要改前端代码。这是非常划算的设计，可以极大降低后续扩展成本。
4. 前端工程：Vue 3 + 组件库 + 前后端联调方案
前端是用户直接面对的部分，决定系统有没有口碑。设计上并不强调花哨效果，核心诉求是信息清晰、操作路径短、权限控制到位。
4.1 工程搭建：Vite 和 TypeScript 的选择
Vue 3 工程化现状来看，Vite 是最优解。开发环境冷启动几乎不需要等待，热更新毫秒级，相比老牌打包工具体验较大幅提升。只考虑浏览器端 SPA 应用，Vite 的配置也非常简洁。
是否使用 TypeScript？我个人的结论是：系统开发用 TS 值得，但要求团队已建立 TS 使用的代码规范，否则反而拖慢节奏。内部系统业务逻辑集中在表单和接口之间，类型错误往往出现在联调阶段，有类型定义时排查成本低一些。但如果你是单兵作战或团队不熟 TS，纠结时间不如先加快推进，后期数据接口文档用工具生成也行。
创建工程的命令：
npm create vite@latest frontend -- --template vue-ts这一步会生成标准目录结构，入口在src/main.ts，根组件在src/App.vue。
4.2 组件库选型与布局框架
我实际对比下来，市面上主流组件库在国内企业项目里还是比较有优势的。表格、表单、树组件、上传组件都很齐全，中文文档完善，遇到问题搜索很容易找到答案，适合没有专职前端的团队。组件库内嵌了布局组件，侧边栏菜单、头部区域一站式搞定，省去自己维护路由菜单的麻烦。
系统采用的布局模式：左侧菜单栏，顶部用户区和消息提醒，主内容区用路由渲染。页面内以表格 + 抽屉式表单为主，审批详情用描述列表展示。
4.3 前端请求层：Axios 拦截器与 Token 刷新
所有接口请求统一封装在src/utils/request.ts，核心是 request 拦截器自动加 Token， response 拦截器统一处理错误码。一段典型配置如下：
import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('access_token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response?.status === 401) { ElMessage.error('登录已过期，请重新登录') localStorage.clear() router.push('/login') } else { ElMessage.error(error.response?.data?.msg || '网络异常') } return Promise.reject(error) } )统一的错误拦截异常处理，业务代码里就能专心处理正常逻辑。
有一点要注意：Token 存哪里？localStorage方便但容易被 XSS 读取，sessionStorage关闭浏览器即失效，持久化登录需求又牺牲体验。内部系统的安全级别下，我用localStorage配合 Content Security Policy 做了基础防护。安全级别要求极高的场景，可以考虑把 Token 放在 HttpOnly Cookie 里，但方案复杂度会上升不少。
4.4 路由守卫与页面级权限控制
登录状态用 Vue Router 的路由守卫控制：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('access_token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })页面级权限按角色过滤菜单。用户登录后，后端返回该用户可访问的菜单列表或权限码列表，前端用这些信息动态生成侧边栏菜单。按钮级别控制在组件里封装一个自定义指令，权限码不满足时直接移除按钮 DOM。
这里有个经验：权限码不只控制前端显示，后端接口必须二次校验。前端隐藏按钮只是体验层面的优化，恶意请求可以直接绕过。后端每个敏感操作都要检查当前用户角色或权限码。
4.5 表单渲染与动态组件
对应后端表单引擎，前端做一个动态表单渲染器：
<template> <el-form :model="formData"> <el-form-item v-for="field in fieldConfig.fields" :key="field.name" :label="field.label"> <el-input v-if="field.type === 'input'" v-model="formData[field.name]" /> <el-select v-if="field.type === 'select'" v-model="formData[field.name]"> <el-option v-for="opt in field.options" :key="opt" :label="opt" :value="opt" /> </el-select> <el-date-picker v-if="field.type === 'date'" v-model="formData[field.name]" /> </el-form-item> </el-form> </template>这个组件树逐步扩展新的字段类型即可。别人想加一种“金额”类型，后端配置时加一行，前端渲染器加一个el-input-number分支，很轻快。
4.6 文件上传与导出细节
附件上传一般用组件库自带上传组件，加一个自定义 action 指向后端上传接口。后端要做的两件事：存文件（建议放到单独的 uploads 目录，并用 UUID 重命名避免文件名冲突），以及把文件路径和元信息写入数据表。下载时用一个静态文件路由暴露 uploads 目录。
文件导出使用后端生成 Excel 的思路，前端直接下载。前端用window.open或创建隐藏<a>标签引导下载是最简单的方式。这里容易踩的坑是 Token 认证：浏览器直接访问下载链接不会自动带 Authorization 头，后端这个导出接口要单独处理 Token 校验。我用的方案是前端把下载请求改成用axios发起，拿回 Blob 数据再通过URL.createObjectURL生成下载链接，一样能触发下载且 Token 正确携带。
5. 开发环境：PyCharm 配置与前后端并行调试
后端推荐用 PyCharm，元老级别的 IDE，由于我们后端是 Python，团队配合里选它省心不少。整个开发流程中，前后端并行调试是最容易陷入混乱的环节，关键是把两件事处理好：虚拟环境和企业版的调试能力。
5.1 PyCharm 虚拟环境与依赖锁定
PyCharm 中新建项目时选择虚拟环境目录，之后所有依赖用requirements.txt锁定版本，避免“在我电脑上是好的”这种经典问题。
我的习惯是把依赖分两个文件：requirements.txt放基础依赖，requirements-dev.txt放开发用的调试工具。部署到生产时只需要基础依赖，体积小也更安全。
5.2 企业版 Flask 调试与断点技巧
PyCharm 专业版对 Flask 有原生支持。配置好项目根目录和调试端口后，以 Debug 模式启动 Flask，然后就可以在视图函数里打断点，查看每个变量状态。比起满屏 print，调试效率有明显提升。
具体操作路径是：Run -> Edit Configurations -> 新建 Flask Server -> 填好 Target 类型和选择启动文件。前端的调试则直接用浏览器开发者工具，但 Chrome 的 Network 面板要配合 Vue DevTools 一起用，看接口返回和组件数据都比较直观。
5.3 前后端并行调试：代理转发与 Mock 数据
并行开发时，前端请求要指向本地后端服务。前端开发服务器的端口通常是 5173，后端 Flask 可能是 5000 端口。跨域问题需要在前端 Vite 开发服务器配置代理，解决跨域问题的同时让 HTTP 请求路径保持简洁：
// vite.config.ts export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:5000', changeOrigin: true } } } })这样前端所有访问/api/xxx的请求都会自动转发到http://localhost:5000/api/xxx，对外表现为同源，不用处理 CORS，后端也不用开发额外的跨域中间件。
并行开发的后半段，等前端页面初始化进入尾声，后端接口也陆续就位后，逐步把 mock 数据切换成真实接口数据，保持联调节奏顺畅。
5.4 代码版本管理与协作规范
项目不大但多人协作，分支管理建议简化为：主干 + 功能分支。每个开发者从主干拉功能分支，开发完合并回主干，合并前进行 Code Review。提交信息要有规范，直接写清楚这次改了什么东西。
PyCharm 的 Git 集成做得相当顺手，View -> Tool Windows -> Commit 可以完成绝大多数提交和推送操作。但代码冲突最好还是用外部成熟 Git 工具解决，比 IDE 内置的合并工具二元冲突处理逻辑更清晰。
6. 联调阶段的黑榜：跨域、鉴权、时间格式化等问题排查
前后端联调阶段是最容易让人心态爆炸的阶段。以下我记录的是最容易踩的坑，这里整理成速查表：
6.1 高频问题速查表
| 现象 | 根因 | 快速排查方法 |
|---|---|---|
| 前端请求 404 | 后端路由或代理路径不一致 | 看浏览器 Network 面板，确认请求最终打到哪个端口和路径 |
| 请求 500 | 后端业务异常或数据库连接问题 | 看后端终端日志，定位异常堆栈 |
| 登录后请求仍 401 | Token 没有正确传到后端或过期 | 看请求头的 Authorization 字段，确认 Bearer 前缀格式 |
| 跨域报错（CORS error） | 开发时未配置代理且后端未开 CORS | 优先用代理；服务端 CORS 手段直接加响应头 |
| 时间是 UTC 时区 | 前后端未统一时间处理逻辑 | 前端格式化时用本地时区读时间戳，或约定时间戳统一单位 |
| 大表单提交超时 | 后端处理过慢或请求体过大 | 考虑调整超时参数，拆分接口或压缩附件 |
6.2 时间格式化：后端默认 UTC 导致的坑
这是个非常隐蔽但极易碰到的问题：SQLite 数据库的created_at保存了带时区信息的时间，前端格式化时直接带上来，用户看到的时间比实际时间少了 8 小时。
根本原因是数据库和操作系统时区不一致，后端写入时间刻度时没有显式指定时区。解决时统一标准：后端全部存时间戳整数，或者统一按本地时间写入，前端展示时才做格式化。我的经验是，数据库里统一存本地时间的 datetime 就行，项目不涉及全球用户，没必要为 UTC 增加复杂度。
6.3 权限配置“改不动”的排查思路
后台修改角色权限后，用户刷新页面发现权限没变。最可能的原因是 Token 里的权限信息是从登录逻辑里读取的，没有实时同步数据库里的最新权限。解决办法有两种：
一是前端登录后拉取一次用户信息，会话期间作为缓存，修改权限后强制要求用户重新登录。二是把权限数据缓存在服务端内存或 Redis 里，每次校验权限时实时读取，权限变更立即生效。内部系统推荐第一种，简单且容错性足够。
6.4 上传文件失败的常见原因
上传功能联调时经常出现两个问题：一是文件太大超过 Flask 默认上传限制，需要在配置里显式设置MAX_CONTENT_LENGTH；二是上传后下载路径不对，检查是否有正确的静态路由映射。
我习惯在上传接口里限定文件类型白名单和大小上限，并在前端设置同步限制，双保险。上传后在后端把文件名统一改成 UUID 加原后缀，能有效避免中文文件名带来的编码问题。
6.5 数据库迁移的版本控制
系统从开发期进入上线期，表结构大概率还会调整数次。不要直接手工改数据库字段，要用迁移工具。Django 自带迁移命令，Flask 需要配合扩展，但效果一致：每次模型变更都生成一次迁移脚本，记录在版本控制里。这样任何人的本地库、测试库、生产库都能通过执行迁移脚本得到一致的表结构。
版本控制在开发阶段的好处尤其明显：同事拉完代码后，执行一次迁移就能得到相同的表结构，而不用手工建表或手动加字段，也避免生产库改了一半、少了一半的尴尬。
7. 上线部署与后续迭代
开发完成只是第一步，内部系统最终要稳定运行，部署方式决定上线后的省心程度。
7.1 前端构建和后端服务启动
前端用npm run build打包，输出到dist目录。部署层面，理想方案是 Nginx 直接托管静态文件，再通过反向代理把/api请求转发给后端服务。结构如下：
前端静态文件由 Nginx 直接负责，访问根路径时返回前端入口 HTML。后端的 Flask 服务启动在 5000 端口，Nginx 匹配到/api前缀时转发给这个端口。
这样部署的好处是生产环境完全同源，没有跨域问题。后端的请求入口只有 Nginx，外部不直接暴露后端服务端口，减小安全面。
后端生产环境启动不要用开发服务器，应该用成熟的生产方案，例如gunicorn启动多进程，并配好 Supervisor 或 systemd 管理进程，确保异常退出后自动拉起。
7.2 备份策略
数据库的备份是无纸化系统最重要的维护工作。审批单、报销单这些数据一旦丢失，不只是恢复麻烦，还有合规风险。建议每天凌晨做一次数据库文件备份或 SQL 导出，保留最近三十天，且备份文件不要放在和系统同一台服务器的同一块磁盘上。我在实际项目中见过服务器磁盘损坏导致备份和源文件一起丢失的问题，这种教训很深刻。
附件文件同样重要，考虑按月度归档上传目录，并同步一份到公司文件服务器。
7.3 功能迭代路线
上线后按真实使用反馈迭代。优先级建议：
- 第一优先级：补上通知机制，审批到达时通过站内信或即时通讯机器人提醒当事人，否则流程容易卡住。
- 第二优先级：分时段数据统计面板，管理员每周点开就能看到各类型单据审批数据，替代手工导出查询。
- 第三优先级：查询通用化，所有单据支持组合条件和模糊搜索。
审批流引擎如果确实出现并列会签、加签、转审等高级场景，再引入成熟的流程引擎或扩展模块，不必一开始就背上过重的引擎包袱。
我个人在这个项目上的最大体会，是技术选型之外，真正的复杂度集中在“流程表达”和“权限控制”这两件事上。把状态机理清楚，把 RBAC 扎扎实实做完，系统就已经稳了一大半。还有一个很实用的建议：开发时顺手把接口文档写完整，哪怕只是用表格记录每个接口的入参和出参，后续自己维护都比翻代码快得多。无纸化办公系统这种业务型系统，逻辑本身没有太高难度，但认真对待细节，项目交付后的维护成本会显著下降。
