说实话，第一次接到"做个报销系统"的需求时，我内心是有点不屑的：不就是一张表单加一个审批按钮吗。等我把需求聊完、把流程跟了一遍，才发现报销这个场景远没有表面看起来那么简单。它是企业里最日常、也最容易扯皮的事务——员工觉得"报个钱怎么这么慢"，财务觉得"天天审你这些破票据还干不干活了"，老板更关心"钱花哪了、合不合规"。所以基于 Python + Flask + Vue 来设计实现一套企业财务电子报销系统，核心难点根本不在增删改查，而在流程、权限和数据一致性。
这篇把从需求分析、表结构设计、后端接口、前端页面到部署上线的完整过程都整理出来，包括那些只有真正做过了才会知道的坑。如果你正打算搞一套类似的系统，不管是毕业设计还是公司内部工具，希望这篇能帮你省下几天的排查时间。
1. 需求盘点：报销单背后是一套角色与流程的博弈
1.1 三类核心用户，三种完全不同的操作习惯
做系统之前，先别急着打开编辑器。我习惯把用户先列出来，因为报销系统最大的特点就是同一套数据，三类人用着三种心态。
普通员工要的是"简单"：填单别让我选太多字段，发票拍个照传上去，提交完等着就行。部门经理要的是"快"：手机上点开就能看到待审批数量，一键通过，偶尔驳回一下。财务人员要的是"严"：每张单子的金额、明细、发票编号都要核对，还得能导出报表对账。至于系统管理员，他关心的是部门、用户、角色这些基础数据怎么维护。
这个系统里我设计了四种角色：employee（普通员工）、manager（部门经理）、finance（财务）、admin（系统管理员）。注意，角色并不是简单的"一个用户一个角色"，现实中一个人可能既是部门经理又是普通员工——他给自己报差旅费的时候应该走员工流程，审批下属的时候走经理流程。所以我没用复杂的多角色中间表，而是用role字段加一个dept_id，审批时判断"申请人的部门经理是谁"来决定谁来审，这样更贴合小企业的实际情况。
1.2 核心流程：从填单到打款要经过哪几道门
报销流程如果画出来，大概是这么一条线：
草稿(draft) → 已提交(submitted) → 经理通过(manager_approved) → 财务通过(finance_approved) → 已打款(paid)
中间随时可能进入已驳回(rejected)，而驳回之后不是流程结束，而是员工修改后重新提交(submitted)。这个"驳回后重新提交"是最容易在设计阶段被忽略的，很多半吊子系统会在驳回后直接把单据锁死，搞得员工只能重新录一张单子，非常反人性。
另外一个关键问题是撤回。员工提交后发现自己金额填错了，在经理还没审批的时候应该允许撤回（draft 状态）。一旦经理已经审了，就不能撤了，只能等驳回或走线下沟通。这个规则写进状态机里，比在界面上堆按钮管用得多。
1.3 需求阶段必须明确的三件事
这几件事是跟客户或者导师反复对齐之后才确认下来的，缺一不可：
- 审批层级要固定吗？我见过有的公司要三层审批（经理→总监→财务），有的只要一层。这套系统做的是两层（经理→财务），但把审批节点设计成可配置的会在后期省很多事。我没做全动态配置，因为维护成本太高，但在状态机里预留了扩展位。
- 需要预算控制吗？第一版没做部门预算，因为客户连自己的预算规则都说不清楚。后来数据量上来之后才补了一个简单的"部门月度报销上限提醒"。如果你现在做，建议至少把
budget字段留在部门表里，别学我后面返工。 - 发票怎么处理？客户最初说"要能自动识别发票"，被我用"OCR识别准确率不够、公司没预算接第三方服务"这个理由劝回去了。最后做成附件上传 + 手工填写发票号，实际用下来完全够。
2. 技术选型：Flask + Vue 这对组合的底气在哪里
2.1 后端为什么选 Flask 而不是 Django 或 FastAPI
别人问我为什么不用 Django，我的回答是：这不是技术优劣问题，是匹配度问题。报销系统这种企业内部工具，核心诉求是快速交付、结构清晰、团队成员能快速上手。Flask 轻量，一切从一个app = Flask(__name__)开始，没有 Django 那一大套自带后台和 ORM 规矩，写起来心理负担小很多。
当然 FastAPI 现在很火，如果你想做高并发接口，它确实有异步优势。但报销系统的并发量摆在那里——一个几百人的公司，高峰期同时在线也就几十人，Flask 的同步模型完全扛得住。而且 Flask 生态成熟，SQLAlchemy、Migrate、JWT 扩展都有现成的，文档多，遇到问题一搜就有答案。
我选择的配套库也列一下，都是经过实际验证的稳定组合：
| 用途 | 库 | 说明 |
|---|---|---|
| ORM | Flask-SQLAlchemy | 简单可靠，配合 Migrate 做迁移 |
| 登录鉴权 | PyJWT | 自己封装装饰器，比 Flask-JWT-Extended 更可控 |
| 跨域 | Flask-CORS | 前后端分离必备 |
| 参数校验 | marshmallow | 比手写 if 判断优雅，后面细说 |
| 文件上传 | 原生 request.files | 报销附件量不大，不需要 Celery 那套 |
2.2 前端为什么选 Vue + Element
前端这块，Vue 上手曲线比 React 缓一点，配合 Element UI（现在叫 Element Plus）做后台管理页面几乎是开箱即用：表格、表单、弹窗、日期选择器全都有，做出来的界面虽然不是惊艳，但胜在工整，业务系统要的就是工整。
Vue 2 和 Vue 3 之间我选了 Vue 3。虽然 Vue 2 的生态更成熟，但 Element Plus 已经跟进 Vue 3 很久了，新项目没必要再守着旧版本。组合是Vue 3 + Vite + Vue Router + Pinia + Axios + Element Plus，这一套下来开发体验很顺。
2.3 前后端分离的目录与接口规范
前后端分离之后，最大的问题不是技术，而是接口规范没对齐。我在项目一开始就定了一个返回格式：
{ "code": 0, "msg": "success", "data": {} }code为 0 表示成功，非 0 表示业务错误（比如 1001 表示登录过期，1002 表示权限不足）。前端 Axios 响应拦截器里统一处理，data里再放业务数据。这个约定写进 README 第一行，后来前后端联调基本没因为返回格式吵过架。
后端目录用 Blueprint 按模块拆，前端按页面拆，对应关系很清晰：
backend/ app.py models/ # SQLAlchemy 模型 views/ # auth.py / reimbursement.py / finance.py utils/ # jwt_helper.py / file_helper.py frontend/ src/views/ # Login.vue / ReimburseList.vue / ReimburseEdit.vue ...3. 数据库设计：把"报销"这件事拆成四张核心表
3.1 user 表：角色权限是审批流的前提
用户表不复杂，但有一个字段特别容易漏：dept_id。审批流的核心逻辑是"找到申请人的部门经理"，没有dept_id，你就得另写一张部门成员表，走一趟弯路的教训我现在还记得。所以我的 user 表长这样：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | int PK | 自增主键 |
| username | varchar(64) | 登录名，唯一 |
| password_hash | varchar(128) | 用 werkzeug 生成哈希，绝不存明文 |
| real_name | varchar(32) | 真实姓名 |
| dept_id | int | 所属部门 |
| role | varchar(16) | employee / manager / finance / admin |
department 表里有一个manager_id字段，指向部门经理的用户 id。这样查询"这张报销单该谁审批"就一句话：SELECT manager_id FROM department WHERE id = 申请人的dept_id。
3.2 reimbursement 主表：金额用 DECIMAL 而不是 Float
报销单主表是整个系统的核心，设计的时候我特别提醒自己一件事：金额字段绝对不能用 Float。Python 的 Float 在二进制浮点运算下会出现0.1 + 0.2 != 0.3的情况，报销金额算错了是会出大问题的。SQLAlchemy 里我用Numeric(10, 2)，Python 里用Decimal做运算，存到数据库是字符串类型，完全避开浮点误差。
主表还记录了一条报销单的完整生命周期：当前状态、申请人、所属部门、报销类型、总金额、申请时间、审批完成时间。其中type字段我用了字符串而不是数字，比如"travel"、"office"、"entertain"、"other"，字符串可读性远好过数字，查询的时候写WHERE type = 'travel'一眼就能看懂。
3.3 明细表、附件表与审批记录表
明细表的作用是把一张报销单拆成多笔费用。比如一次出差，可能有交通费 800、住宿费 1200、餐费 300。明细表记录了每一笔的日期、类别、金额、说明，财务审批时能逐条核对。这里有个前端交互上的设计点：明细是动态行，员工可以点"添加一行"继续加，这个等讲前端的时候再展开。
附件表记录上传的发票图片或 PDF。字段包括文件名、存储路径、大小、上传时间。存储方式我选的是本地磁盘路径（upload/2025/03/xxx.jpg），而不是把文件直接塞进数据库。大文件进数据库会让备份变得很痛苦，本地存储加一个外键关联就够了。
审批记录表是审计需求的关键。每一次审批动作都留一条记录：谁审的、审了什么状态、批注了什么。这样一旦员工说"我没收到驳回通知"，翻记录表就能看到驳回的操作人和时间。我还加上了previous_status和next_status两个字段，完整还原状态流转路径。
3.4 索引与查询：审批列表为什么越用越慢
系统上线第三周，财务就跟我抱怨"列表加载越来越慢"。我一看，报销单表已经有两千多条数据，而审批列表的查询条件是WHERE status = 'submitted'，这个字段没有索引，每次都是全表扫描。
加索引这件事真的是"早期偷懒，后期还债"。我当时一口气补了三个索引：
CREATE INDEX idx_reimb_status ON reimbursement(status); CREATE INDEX idx_reimb_user ON reimbursement(user_id, created_at); CREATE INDEX idx_reimb_dept ON reimbursement(dept_id, status);第一条解决审批列表慢查询，第二条解决"我的报销记录"页面的分页，第三条是给财务做部门维度统计用的。加了之后列表查询从几百毫秒降到几十毫秒。这里也分享一个经验：写查询之前先想清楚筛选条件，把索引设计进表结构里，比事后EXPLAIN再补要舒服得多。
4. 后端实现：登录鉴权、审批状态机与文件上传
4.1 JWT 登录鉴权的落地写法
前后端分离的项目，会话管理基本都选 JWT。我的做法是登录成功后签发一个有效期 12 小时的 token，把user_id和role放进 payload。之所以要在 token 里放角色，是为了让后端接口做权限校验时不用每次查一遍数据库——虽然这样会有一个角色变更后 token 未过期仍然有效的窗口，但企业内部工具完全可以接受。
自定义装饰器的核心代码：
from functools import wraps from flask import request, g, jsonify import jwt def login_required(fn): @wraps(fn) def wrapper(*args, **kwargs): token = request.headers.get("Authorization", "") token = token.replace("Bearer ", "") try: payload = jwt.decode( token, current_app.config["SECRET_KEY"], algorithms=["HS256"] ) g.user_id = payload["uid"] g.role = payload["role"] except jwt.ExpiredSignatureError: return jsonify({"code": 1001, "msg": "登录已过期，请重新登录"}), 401 except jwt.InvalidTokenError: return jsonify({"code": 1002, "msg": "无效的登录凭证"}), 401 return fn(*args, **kwargs) return wrapper def role_required(*roles): def decorator(fn): @wraps(fn) def wrapper(*args, **kwargs): if g.role not in roles: return jsonify({"code": 1003, "msg": "没有操作权限"}), 403 return fn(*args, **kwargs) return wrapper return decorator用法就是视图函数上叠两个装饰器：
@bp.route("/approve", methods=["POST"]) @login_required @role_required("manager", "finance") def approve(): # 审批逻辑 ...注意装饰器顺序，login_required必须在下面（先执行），这样g.role才会先被赋值。
4.2 报销单状态机的设计与边界
状态机是整个后端的灵魂。我一开始是用一堆 if-else 写的，后来发现边界情况越来越多，干脆改成字典驱动的状态流转表：
ALLOWED_TRANSITIONS = { "draft": ["submitted"], # 草稿只能提交 "submitted": ["manager_approved", "rejected", "draft"], # 经理通过/驳回，或员工撤回 "manager_approved":["finance_approved", "rejected"], # 财务通过/驳回 "finance_approved":["paid"], # 财务打款 "rejected": ["submitted"], # 驳回后修改重新提交 "paid": [], # 终态，不可变 }每次状态变更，先查ALLOWED_TRANSITIONS[current_status]，如果目标状态不在列表里，直接拒绝并返回"当前状态不允许此操作"。这样写的好处是：所有流转规则集中在一处，不可能出现某个视图函数里漏判状态的情况。
提交报销单的接口上还做了一件很重要的事：只有草稿状态的单子能编辑和删除，一旦进入 submitted 就必须走审批流。这个约束在状态机之外再加一道检查，双保险。
4.3 审批接口的并发控制
这个坑是我在测试阶段发现的。两个审批人同时打开同一个待审单据，一个点了"通过"，另一个也点了"通过"，如果代码是"先查状态，再更新状态"，那第二次更新就会把第一次的记录覆盖掉，审批记录表里出现两条"通过"，状态却只变了一次。
解决办法很简单，用 UPDATE 的影响行数来判断是否并发冲突：
from sqlalchemy import update def approve(reimbursement_id, expected_status, new_status): result = db.session.execute( update(Reimbursement) .where(Reimbursement.id == reimbursement_id, Reimbursement.status == expected_status) .values(status=new_status) ) if result.rowcount == 0: db.session.rollback() return jsonify({"code": 2001, "msg": "单据状态已变化，请刷新后重试"}), 409 db.session.commit() return jsonify({"code": 0, "msg": "success"})先 UPDATE 再判断rowcount，等于把"校验状态+更新状态"合并成了一个原子操作，数据库层面的行锁帮我们挡住了并发。这个写法很简单，但能挡住绝大多数并发问题。
4.4 发票附件上传的校验细节
文件上传看起来简单，实际上坑最多。第一版我什么都没限制，结果有人传了个 50MB 的发票扫描件，服务器磁盘差点被塞满。后来加了三道校验：
ALLOWED_EXTENSIONS = {"png", "jpg", "jpeg", "pdf"} def validate_file(file): # 1. 文件存在性 if not file or file.filename == "": return False, "请选择文件" # 2. 扩展名白名单 ext = file.filename.rsplit(".", 1)[-1].lower() if "." in file.filename else "" if ext not in ALLOWED_EXTENSIONS: return False, "仅支持 png/jpg/jpeg/pdf 格式" # 3. 大小限制（5MB） file.stream.seek(0, 2) size = file.stream.tell() file.stream.seek(0) if size > 5 * 1024 * 1024: return False, "文件大小不能超过 5MB" return True, ""文件名我也没有直接用原始文件名，而是用uuid4().hex + ext重命名，避免中文文件名、特殊字符带来的路径问题。存储目录按月份分（upload/2025/03/），方便后续定期清理过期附件。
有些细节容易被忽略，说一下：发票是敏感信息，附件在传输和存储上建议实际使用中做访问控制。基础做法是附件接口也要校验登录态，而且不允许按文件名直接猜路径访问，我加了一个attachment_token，只有带着有效 token 才能预览，成本不高但能挡掉不少随意扫描。
5. 前端实现：从表单校验到审批流交互
5.1 路由守卫：前端权限只是体验优化
前端路由守卫要做，但要清醒：它只是体验优化，不是安全边界。router.beforeEach里检查 token 是否存在、角色是否匹配，目的是让没权限的人看不到入口，而不是真的拦住他——真正拦人的是后端装饰器。
router.beforeEach((to, from, next) => { const token = localStorage.getItem("token") if (to.meta.requiresAuth && !token) { next({ path: "/login", query: { redirect: to.fullPath } }) return } const role = localStorage.getItem("role") if (to.meta.roles && !to.meta.roles.includes(role)) { next({ path: "/403" }) return } next() })菜单也是根据角色动态渲染的：财务看到"审批管理"和"报表统计"，普通员工看到"我的报销"，经理比员工多一个"部门审批"。这个逻辑放在前端用v-if控制即可，不值得上复杂的动态路由方案。
5.2 动态明细表单：报销单填写页的核心
报销单填写页是员工每天要面对的页面，交互设计比想象中重要。核心功能是动态明细，员工点一下"添加明细"就多一行输入。这里我用 Element Plus 的el-table加上操作列实现，每一行里包含日期、费用类别、金额、说明四个字段。
加行容易，校验难。我踩过的坑是：如果校验规则只绑定在form对象上，动态添加的行不会自动触发校验。解决办法是在新增行时同步给校验规则数组push一个空对象，删除时splice。
另一个细节：金额合计要实时计算。员工填明细的过程中，右上角的"合计金额"要跟着变，让他心里有数。这个用计算属性computed遍历明细数组累加Decimal(Number(行金额))，同时把合计回填给主表单。
提交前还有一道完整校验：必须有至少一条明细、每行金额大于 0、总金额大于 0、报销类型不能为空、申请理由至少要写一句话。这些规则全部用 Element Plus 的rules配置，错误提示放在字段下面，员工不用猜哪里错了。
5.3 审批人视角：列表、详情与操作反馈
审批人进入系统，第一个看到的是"待我审批"列表。这个列表我按状态分了 Tab：待审批、已通过、已驳回。每一行显示申请人、部门、金额、提交时间，右上角标一个红点数字表示待办数量，这也是经理们最关心的数字。
点进详情，用抽屉（Drawer）而不是新开页面。抽屉的好处是：审批人看着详情的同时，底部始终有"通过"、"驳回"两个按钮在视野内，不需要滚动页面底部去找按钮。驳回的时候强制要求填驳回原因——不做强制的话，很多人直接点驳回，员工根本不知道改哪里，来回拉扯好几轮。
操作成功之后，前端做一个非常明确的反馈：通过显示绿色提示、驳回显示红色提示，然后自动刷新待办列表的数字。审批是高频重复操作，反馈必须"重"，让审批人不用思考就知道刚才那下点成功了。
5.4 Axios 拦截器与错误提示规范
Axios 拦截器统一处理三件事：附带 token、统一拆包、统一错误提示。
service.interceptors.request.use((config) => { const token = localStorage.getItem("token") if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( (response) => { const res = response.data if (res.code !== 0) { ElMessage.error(res.msg || "操作失败") if (res.code === 1001) { localStorage.clear() router.push("/login") } return Promise.reject(new Error(res.msg)) } return res.data }, (error) => { if (error.response?.status === 401) { ElMessage.error("登录已过期，请重新登录") localStorage.clear() router.push("/login") } else { ElMessage.error("网络异常，请稍后重试") } return Promise.reject(error) } )这个拦截器让页面代码非常干净，每个接口调用处只需要await拿到data，异常情况全部集中处理。一个细节：ElMessage.error不要连续弹太多条，我加了一个messageQueue数组做去重，防止连点按钮时弹出五六条重复提示把用户怼到烦躁。
6. 联调与部署：跨域、并发和数据安全的全套解决方案
6.1 跨域配置的完整姿势
前后端分离，本地开发时前端跑在 5173 端口，后端跑在 5000 端口，跨域问题必须一开始就解决。我的做法是后端用 Flask-CORS 全开：
from flask_cors import CORS CORS(app, supports_credentials=True, resources={ r"/api/*": {"origins": ["http://localhost:5173", "http://127.0.0.1:5173"]} })注意两点：第一，supports_credentials=True必须加，否则携带 cookie 的请求会被浏览器拦截；第二，生产环境不要图省事设成*，只允许正式域名，否则别人从任何网站发请求都能调你的 API，我再强调一下：安全边界一定要立住。
不配置的话，典型的报错是浏览器控制台里出现Access to XMLHttpRequest at '...' from origin '...' has been blocked by CORS policy，新手容易被这个吓住，其实一行配置就解决。
6.2 并发审批的乐观锁实践
前面第 4.3 节讲了审批接口的乐观锁写法，这里再补充一个真实测试的细节。我用测试脚本模拟两个用户同时审批同一张单子：
import threading import requests url = "http://127.0.0.1:5000/api/reimb/approve" def approve_as(uid, token): resp = requests.post(url, json={ "reimbursement_id": 88, "action": "approve" }, headers={"Authorization": f"Bearer {token}"}) print(f"用户{uid}: {resp.json()['msg']}") t1 = threading.Thread(target=approve_as, args=(1, token_1)) t2 = threading.Thread(target=approve_as, args=(2, token_2)) t1.start() t2.start()跑完之后，一个返回成功，一个返回"单据状态已变化"，数据表里也只有一条审批记录。这个结果就是乐观锁该有的表现——宁可让一个人重试，也不能让两个人都以为审批成功了。
6.3 数据安全：密码哈希、票据与操作日志
数据安全这块我做了三件事，都不复杂但必须有。
密码不用明文也不用普通的 MD5，而是用werkzeug.security.generate_password_hash生成 PBKDF2 哈希，校验用check_password_hash。这个库是 Flask 自带的依赖，直接用就行。
发票附件属于敏感数据，我限制只有登录用户可以访问，而且打开附件要经过后端鉴权接口。上面说的attachment_token有效期设成 10 分钟，过期重新申请，够用的同时也不会长期暴露在 URL 里。
最后是操作日志。除了审批记录表之外，我还建了一张operation_log表，记录谁在什么时间对哪张单子做了什么操作（新增、编辑、提交、撤回、审批）。这张表的写入放在after_request钩子里异步处理，不影响主流程响应速度。
6.4 gunicorn + Nginx 部署的坑
部署用的是经典的gunicorn + Nginx方案，Flask 自带的开发服务器绝对不能用在生产环境。启动命令：
gunicorn -w 4 -b 127.0.0.1:5000 app:app-w 4表示 4 个 worker 进程，对于这种量级的系统完全够。这里有个坑：多 worker 情况下，如果你把附件存到了本地磁盘，那么轮询到不同 worker 时读文件不受影响（因为读的是同一磁盘路径），但如果用的是内存缓存（比如默认的werkzeug.local），Session 会失效。所以我的方案是：附件存磁盘 + 登录用 JWT（无状态），完全不依赖 worker 内的内存状态。
Nginx 配置里需要注意两个点：第一，client_max_body_size要调大，不然上传文件会被 Nginx 层直接 413。我设成了 10m。第二，静态资源（前端打包后的 dist 目录）由 Nginx 直接服务，API 请求反向代理到 gunicorn：
server { listen 80; server_name your-domain.com; client_max_body_size 10m; root /var/www/reimburse/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:5000; 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 /upload/ { alias /var/www/reimburse/upload/; expires 7d; } }try_files ... /index.html那一行是给 Vue Router 的 history 模式用的——刷新一个非根路径的页面时，Nginx 要兜底把请求交给index.html，否则会出现404。
7. 上线后的真实反馈：从"能用"到"好用"的迭代
7.1 审批时长从三天压到几小时
系统上线一个月后，我拉了审批耗时数据：平均每单从提交到财务通过，耗时 2.8 天，其中大部分时间耗在"经理不知道自己有待审批的单子"。
于是我在前端加了两个东西：一是部门经理登录后首页展示待办卡片，二是报销单提交后给经理发一封通知邮件（用 SMTP 发的，数据库查一下manager_id就能拿到邮箱）。就这两步，平均审批时长降到了 6 小时以内。
这个数据变化再次印证了一件事：业务流程系统的瓶颈往往不在系统本身，而在信息触达。系统能做的是把"谁该干嘛"变成明确的待办，而不是靠人工到处问。
7.2 统计报表和预算提醒
第二个迭代是给财务加了统计报表页。用 ECharts 画了两个图：按部门统计月度报销金额的柱状图，按报销类型统计占比的饼图。数据来源是一个独立的统计接口，用一条 SQL 做GROUP BY聚合，没必要引入复杂的 BI 工具。
预算提醒做得更简单：部门表加了一个monthly_budget字段，报销单通过财务审批时，后端查一下该部门本月累计通过金额，如果超过预算的 80% 就在审批界面弹个黄色警告，超过 100% 则要求财务填写超预算说明。这个改动很轻，但对财务的管控价值很大。
7.3 后续可以做的扩展方向
系统到现在运行了大半年，数据量不算大但流程稳定。如果还要扩展，我觉得三个方向最有价值：
- 移动端适配：目前用的是响应式布局，手机能看但体验一般。如果可以接受简单方案，做成微信小程序或者 H5 版填报入口，会让员工填单意愿高很多。
- 发票 OCR 识别：技术上成熟了以后，可以把上传的发票自动识别出金额和发票号，和手工填写的明细做交叉校验。这个需要额外预算，但确实是减负效果最明显的功能。
- 对接财务软件：导出对账单的格式做成和常用财务软件兼容的模板，财务在系统里审核完直接导入做账，能把最后一步的对账时间省下来。
做这个项目最大的体会是：写代码的时间可能只占三成，剩下七成都在理解业务和跟人对齐预期。报销系统尤其如此，它表面上是表单和审批，背后是公司的钱、员工的耐心和管理层的信任。状态机设计好、并发问题处理好、权限边界守好，这套系统就能稳稳当当地跑很久。如果你还卡在表结构或者状态流转那一步，直接从第 3 节和第 4 节开始参考，遇到具体问题欢迎一起聊。
