简介一套基于前后端分离架构的银行流水数据分析系统毕设项目面向计算机相关专业学生及数据分析入门者为解决单一账户多笔资金流向处理与展示的人工筛查问题提供参考。压缩包共56个文件以21个Go后端文件、12个Vue前端文件和10个TypeScript类型定义为主另含配置、样式、文档等支持内容总大小约1.96MB目录结构便于按模块检索。后端集成Gin、Gorm、Viper、Logrus、Casbin与Excelize覆盖Web服务、持久化、配置管理、日志、角色权限控制及表格解析前端基于Vue与TypeScript构建。技术实现上通过Golang反射创建结构体完成用户数据注入并做到数据库表级隔离借助SQL语句上下错行比对识别交易数据不一致实现异常数据标识。已有215人学习适合用来理解银行流水分析场景、权限控制设计及前后端分离项目组织方式。1. 银行流水数据分析系统到底在解决什么问题刚接手这类“银行流水数据分析系统”的毕业设计时最容易犯的错是先找数据、再搭界面最后发现整个系统只是个“能打开 Excel 的图表工具”。实际上面试官和答辩老师真正关心的不是你会不会画折线图而是面对一份几千行的银行流水你能不能设计出“从原始交易记录到资金特征”的完整分析链路。银行流水数据虽然字段少但脏数据多、金额语义含糊、时间跨度长直接套用通用 BI 工具往往得不到稳定结论。这套系统的核心价值在于三件事把不同银行导出的流水文件统一成标准结构把收入、支出、结余、往来对手方等特征算得可靠再让分析结果可验证、可解释。适合的人群不只是准备毕业设计的学生还包括需要做流水尽调、个人信贷辅助判断或企业资金分析的开发者和数据工程师。2. 先把银行流水数据结构化从 XLSX、CSV 到标准交易表2.1 不同银行的导出文件差异比想象中大“银行流水”不是一种标准格式而是同一类业务数据的多个变体。常见的下载渠道分三种网银页面导出、手机银行分享、柜台打印后扫描识别常见文件后缀有.xlsx、.xls、.csv偶尔还有 PDF。字段名更是各行其是同一含义有“交易时间”、“记账日期”、“入账日期”三种写法收入和支出有的银行分成两列有的合并成一列再用“收/支”标记表示有的干脆用正负数区分。这是做流水数据相关系统时必须直面的事实毕设答辩时这部分最容易被提问。我一般会在系统里设计一个“文件解析适配层”而不是在业务代码里到处写if bank ICBC。适配层的输出是一张标准交易表字段固定为字段名类型说明tx_datedate交易日期精确到日即可tx_timevarchar交易时间允许为空尽量保留原始串tx_typevarchar枚举值income / expense / transferamountdecimal(14,2)金额绝对值正数balancedecimal(14,2)该笔交易后的账户余额可能为空counterpartyvarchar交易对手方名称或对方账号remarkvarchar摘要或附言raw_line_hashchar(32)原始行的 MD5用于去重和溯源tx_type不要用中文直接入库统一转成英文枚举值后面算指标时能少写一堆case when。amount与tx_type搭配含义是清晰的income 的 amount 增加余额expense 的 amount 减少余额。raw_line_hash很多人忽略但它是去重和定位脏数据的关键键。2.2 用 Pandas 完成字段对齐与类型修正即使不做复杂的数据治理至少要做格式层清洗。下面这段代码处理的是最常见的“一行内同时有收支方向和金额”的文件import pandas as pd import hashlib def normalize_bill(raw_df: pd.DataFrame, col_map: dict) - pd.DataFrame: df raw_df.rename(columnscol_map) # 1. 统一日期格式部分文件里日期是 2024/1/5 或 20240105 df[tx_date] pd.to_datetime(df[tx_date], errorscoerce).dt.date # 2. 交易类型标准化优先从收支方向列读取 if direction in df.columns: df[tx_type] df[direction].map({收入: income, 支出: expense}) elif amount in df.columns and balance in df.columns: # 部分文件用正负金额表示收支 df[tx_type] df[amount].apply(lambda x: income if x 0 else expense) df[amount] df[amount].abs() # 3. 处理金额里的逗号、人民币符号、全角空格 df[amount] ( df[amount].astype(str) .str.replace(,, , regexFalse) .str.replace(, , regexFalse) .str.replace( , , regexFalse) ) df[amount] pd.to_numeric(df[amount], errorscoerce) # 4. 对手方缺失时取备注折半截断便于后续文本聚合 df[counterparty] df[counterparty].fillna(df[remark].str[:12]) # 5. 生成行指纹保证同一笔交易从不同文件导入时能识别 hash_input ( df[tx_date].astype(str) df[amount].astype(str) df[remark].fillna() ) df[raw_line_hash] hash_input.map(lambda x: hashlib.md5(x.encode()).hexdigest()) return df[[tx_date, tx_time, tx_type, amount, balance, counterparty, remark, raw_line_hash]]参数说明col_map是原始列名到标准列名的映射调用前先打印raw_df.head()确认采样值再把{交易日期: tx_date, 金额: amount}这样的映射传进来errorscoerce保证解析失败的日期不会中断批量导入而是置空金额清洗里的regexFalse是为了避免把逗号误认为正则元字符全角空格的处理建议先encode(utf-8)再替换细节不多但真能省事。2.3 导入后必须做六项质量校验结构统一只是第一步质检是把关分析结论可信度的唯一手段。常见做法是写一个validate_flow(df)函数返回校验报告而不是直接抛异常。2.3.1 校验内容与判定口径校验项判定口径日期连续性当月日期缺失大于 3 天则告警余额自洽性当余额字段非空时计算前一余额 本笔变动是否等于本笔余额金额异常amount 小于等于 0 且 tx_type 非 transfer 时判定为异常重复交易raw_line_hash 出现次数大于等于 2且金额超 1000 时标记对手方缺失率counterparty 空值占比超过 30% 时提示降低文本分析价值时间字段一致性tx_time 为空不能忽略需统计占比占比超 50% 则放弃时间维分析我见过太多毕设项目直接跳过余额自洽校验最后画出的资金曲线前后矛盾答辩时被追问“为什么余额对不上”。其实这个校验不复杂用 shift 就能完成。在上下文中加入report {} df df.sort_values([tx_date, tx_time]) # 计算期望余额上一笔余额 本笔变动再与实际余额比较 prev_balance df[balance].shift(1) delta df[amount] * df[tx_type].map({income: 1, expense: -1, transfer: 0}) expected prev_balance delta mismatch_mask df[balance].notna() prev_balance.notna() (abs(expected - df[balance]) 0.01) report[balance_mismatch_ratio] mismatch_mask.mean()需要注意这段代码的前提是流水中每笔交易的余额都完整且没有任何间隙。多数银行流水满足这一点但跨月导出时可能出现月初第一笔余额就是上月末值shift 判断会报错所以报告里给出的是“不匹配比例”而不是直接断言数据有误。3. 核心分析模块收支、往来对手方与账户特征提取3.1 收入支出统计要选用“期间口径”而不是简单汇总银行流水分析系统里最常用的指标是月收入、月支出、月结余但直接groupby(月份)[amount].sum()会忽略转入转出的语义。实际操作中我把交易分成三类收入类工资、报销、转账收入、支出类消费、取现、转账支出、内部调拨类同名账户互转。在上一章的标准表里transfer已经被单独标记没标记的可以在分析层做二次判断。def monthly_summary(df: pd.DataFrame) - pd.DataFrame: df[month] df[tx_date].astype(str).str[:7] income df[df[tx_type] income].groupby(month)[amount].sum() expense df[df[tx_type] expense].groupby(month)[amount].sum() transfer df[df[tx_type] transfer].groupby(month)[amount].sum() result pd.DataFrame({income: income, expense: expense, transfer: transfer}) result[net_saving] result[income] - result[expense] # 月结余不应包含内部调拨否则资金规模会被重复计算 result[balance_eop] df.groupby(month)[balance].last() return result.fillna(0)参数说明str[:7]是把“2024-03-15”截断成“2024-03”避免to_period带来的时区问题balance_eop取每月最后一笔交易的余额而不是把余额加总这个口径在财务报表里叫“期末时点数”在毕设文档里写清楚这一笔能直接体现对业务的理解。另一个要说明的是“net_saving 不包含 transfer”很多同学把同名账户互转的金额加进净收入导致分析结果出现“月收入 80 万”的失真情况。3.2 交易对手方聚合要解决“同一实体多个名字”的问题对手方字段是流水分析里文本噪声最大的部分。同一家“支付宝”在流水里可能出现“支付宝中国网络技术有限公司”“支付宝-转账”“余额宝-转出”等多种写法。如果简单分组排名前十的“往来对手”会碎片化。常见做法是维护一个关键词归一化字典按优先级做包含匹配。counterparty_rules [ (r支付宝|余额宝|Alipay, Alipay), (r微信|WeChat|腾讯, WeChat), (r工资|代发|薪酬, 代发工资), (rPOS|消费|商户, POS消费), ] df[counterparty_norm] df[counterparty].astype(str) for pattern, label in counterparty_rules: mask df[counterparty_norm].str.contains(pattern, regexTrue, naFalse) df.loc[mask, counterparty_norm] label # 对手方净流入 top10正数表示净收入负数表示净支出 peer_summary ( df.groupby(counterparty_norm) .apply(lambda x: x.loc[x[tx_type] income, amount].sum() - x.loc[x[tx_type] expense, amount].sum(), include_groupsFalse) .sort_values(ascendingFalse) .head(10) )注意include_groupsFalse是 pandas 2.x 处理 groupby 后 apply 时避免分组列混入运算的写法老版本会报警告但结果一致。这个模块完成后还需要输出一个“往来对手方交易频次”表频次比金额更能反映资金往来是否稳定。3.3 账户画像特征的设计要服务后续的异常识别画像特征不要一次算太多挑可解释性强的来。我常用的是下面这组特征每个特征都有明确的业务含义收入集中度最大来源对手方金额占比正常工资卡通常大于 70%异常账户往往分散。夜间交易占比晚 22 点到次日 6 点的支出笔数占比越高说明交易行为越偏离常规。整数交易扎堆金额为整数无角分的笔数占比赌博、套现场景通常显著偏高。快进快出频次单笔大额收入在 3 日内被转出的次数这个特征对识别过渡账户很有价值。月结余波动系数月度净结余的标准差除以均值波动接近 1 的账户资金结构不稳定。feature_df pd.DataFrame(index[account_id]) feature_df[income_concentration] ( df[df[tx_type] income][amount].max() / df[df[tx_type] income][amount].sum() ) feature_df[night_tx_ratio] ( df[tx_time].fillna(12:00:00).str[:2].astype(int).between(22, 23).sum() df[tx_time].fillna(12:00:00).str[:2].astype(int).between(0, 6).sum() ) / len(df)tx_time缺失时填充成12:00:00是因为它既不算夜间也不影响日间比例。这类细节在答辩的代码走查环节非常加分是一眼能看出你处理过真实数据、而不是只说听见过的。4. 用规则引擎实现流水异常检测再叠加一个可视化看板4.1 为什么规则引擎比直接上机器学习更适合毕设银行流水数据分析系统里最容易“为了 AI 而 AI”的模块是异常检测。做毕设时直接用孤立森林或异常编码器AutoEncoder跑一遍数据会面临两个短期无法补齐的短板一是训练数据没有标签无法评估召回率和误报率二是答辩时被问到“为什么把某笔交易标成异常”模型给不出业务能理解的解释。常见的可靠路径是把流水异常识别做成一棵“规则决策表”每一条规则都有触发条件和风险等级后续想升级模型也可以把规则输出当作特征拼进去。规则设计遵循一个原则任何单条规则都不要同时依赖金额和频率之外的高维条件否则难以调参。规则编号触发条件风险等级R01单笔支出 账户三个月平均支出的 8 倍中R02单日累计转入转出前 5 个交易日内转入金额之和的 90% 被转出高R03月收入笔数超过 30 且对手方数超过 10 个且存在整笔金额精确到元中R04同日频繁拆分同一天内对同一对手方交易超过 4 笔金额逐笔递增高R05夜间 23 点至凌晨 2 点发生 3 笔以上 2000 元的支出低4.2 规则引擎的 Python 落地def apply_rules(df: pd.DataFrame) - pd.DataFrame: df df.copy() df[alert_level] low df[alert_rules] # R01单笔大额支出 avg_expense df[df[tx_type] expense][amount].mean() r01_mask (df[tx_type] expense) (df[amount] 8 * avg_expense) df.loc[r01_mask, alert_level] df.loc[r01_mask, alert_level].where( df.loc[r01_mask, alert_level] ! high, high ) df.loc[r01_mask, alert_level] medium df.loc[r01_mask, alert_rules] R01; # R02快进快出按收入后 3 天窗口扫描 income_dates df[df[tx_type] income][tx_date].unique() for dt in income_dates: window_df df[df[tx_date] dt pd.Timedelta(days3)] recent_in window_df[window_df[tx_type] income][amount].sum() recent_out window_df[window_df[tx_type] expense][amount].sum() if recent_in 0 and recent_out / recent_in 0.9: df.loc[df[tx_date] dt, alert_level] high df.loc[df[tx_date] dt, alert_rules] R02; return df[df[alert_level] ! low]这里逐日扫描的性能在分析几万行流水时是可接受的但如果审计场景要处理百万行建议把窗口计算改成向量化的 rolling 值而不是 for 循环。提示规则模块的输入输出要标准化输出数据里alert_rules字段用分隔符拼装便于看板端直接把规则名渲染成中文标签。4.3 看板选型优先考虑能放进答辩演示环境的应用流水分析系统的可视化部分会占据毕设演示一半的时间所以选型标准不是功能多少而是“能不能在本地快速启动、离线可用、方便截图”。用 Django/Vue 做全套前端会花太多时间在接口联调上用 Jupyter Notebook 又显得工程性不足。常见的可靠选择是 Streamlit它天然支持 DataFrame 操作几分钟就能把指标模块包成可交互页面。import streamlit as st st.set_page_config(page_title银行流水数据分析系统, layoutwide) uploaded_file st.file_uploader(上传银行流水文件, type[xlsx, csv]) if uploaded_file is not None: raw_df read_raw(uploaded_file) stdf normalize_bill(raw_df, col_map) stdf apply_rules(stdf) col1, col2, col3 st.columns(3) col1.metric(总收入, f{stdf[stdf[tx_type]income][amount].sum():,.2f} 元) col2.metric(总支出, f{stdf[stdf[tx_type]expense][amount].sum():,.2f} 元) col3.metric(告警交易笔数, len(stdf[stdf[alert_level] ! low])) st.line_chart(monthly_summary(stdf)[[income, expense]])在 Streamlit 的metric组件里金额格式化用了:,.2f小数位会稳定到两位不会出现科学计数法。st.line_chart会自动对索引排序所以传入的数据要保证月份升序前面的monthly_summary()已经按月份字符串排序了这一点可以直接依赖。这类看板后续如果要升级成企业应用再迁移到 FastAPI React 也不迟迁移成本主要集中在解析适配层而分析逻辑都是纯函数这点在文档里提前说明会更有说服力。5. 让毕设更像生产系统的三个细节流水分析系统在演示时能跑通不代表交付完整还有三个细节值得在答辩前补上它们在项目文档里能各占一个二级标题工作量并不大但能显著拉开和同类毕设的差距。第一个细节是增量导入。真实场景下用户会定期追加流水文件而不是每次全量导入。做法是维护一张import_batch表记录每次导入的文件名、文件哈希、导入时间、覆盖日期区间。再次上传时先比对文件哈希相同则不处理若哈希不同但日期区间重叠则提示“存在数据变更是否覆盖”。这个逻辑有 30 行代码就能完成但能让系统从“一次性的脚本”升级为“可持续使用的小工具”。第二个细节是分析结果的字典表。很多人在页面直接把counterparty_norm或alert_rules的枚举值展示出来用户看不懂“R02;R05”是什么意思。给系统加一张metric_dict表存放指标编码、名称、口径说明、参考阈值看板端用st.dataframe的column_config关联字典做中文映射。这会逼着你把每个指标的计算口径写清楚答辩评委追问“净结余怎么算的”时你能直接拿出定义文档。第三个细节是数据脱敏展示。如果系统里还包含客户姓名、完整银行账号这类字段哪怕只是毕设也应该在展示层打码。简单处理是只显示前四位后两位138****4201并在导出报表时提供脱敏开关。核心模块的代码示例是保留原始明细的但对外演示时一定不要开“完整显示”权限。加上这个开关后的效果是在合规层面把系统从“能用”变成了“敢给别人用”。本文还有配套的精品资源点击获取