一套财务系统的研发心得：扎实与创新，是功底也是态度

刚刚完成一套对标金蝶 K/3 标准的 20 大模块财务系统（含 AI 决策、AI 预警、AI 助手），从需求调研、架构设计、业务实现、安全审计到部署上线，走完了一个完整的工程闭环。借这个机会，把研发过程中的逻辑心得与方法论沉淀成文字，与大家分享。

一、先立标准，再写代码

这套系统开发最关键的一点，是没有一上来就写代码，而是先完成了三件事：

• 深度需求调研——把用户提供的金蝶标准模块清单逐条拆解成 11 大板块、30+ 子模块，先把"总账做什么、折旧有几种方法、账龄怎么分段、燃尽图/帕累托图是什么语义"这些业务规则吃透后再动工。
• 架构先行——先定技术栈（Express + sql.js + JWT + 单文件前端），再画数据流、分层架构、40+ 张数据表设计，最后才是实现。
• 以终为始——明确"财务系统必须借贷平衡、必须零缺陷"，所以从第一天就把严谨性刻进了架构。

做对需求，比做快代码更重要。财务系统的严谨性，必须在架构层面就设计进去，而不是事后打补丁。

二、轻量但不简陋的架构

我刻意选择了"单体全栈 + 单文件前端 + SQLite"这套看似"简单"的组合，但这恰恰是深思熟虑的结果：

技术的价值不在于"用得多新、多复杂"，而在于"是否恰到好处"。能用简单方案解决问题，是更高的功力。

三、把"严谨"做成肌肉记忆

财务系统最怕"差不多"。我在核心逻辑上做了三层防护：

• 借贷平衡三重校验——创建、更新、红冲全链路强制 |Σ借 − Σ贷| ≤ 0.01，加上日期有效性、金额非负、每行必选科目、至少一条分录。
• 状态机闭环——凭证草稿 → 已审核 → 已过账 / 已作废 / 已红冲，状态流转有迹可循。
• 期末业务自动化 + 幂等——损益结转、折旧计提、红字冲销全部自动生成凭证，同期间重复结转会被拦截，防止数据被污染。

财务系统的"功力"，藏在那些用户看不见的边界处理里——负金额要拦、空明细要拦、无效日期要拦、重复结转要拦。这些才是真正的功底。

四、零缺陷不是口号，是过程

用户要求"财务系统必须零缺陷、零漏洞、零 Bug"。我没有拍胸脯说"没问题"，而是做了一次系统性审计：

• 双路并行审查——前后端各派一个审查代理，交叉扫描
• 逐项修复——SQL 注入（参数化 + 白名单）、XSS（统一 esc() 转义覆盖全部用户可控字段）、密码明文（SHA-256 + 盐哈希）、权限缺陷（出纳不能审批/建凭证）、崩溃风险（reset 异常捕获）、输入校验（前后端双重）
• 回归验证——31 项测试全通过，用 Playwright 无头浏览器实测权限拦截

审计发现 30 项问题并修复，恰恰是这套系统"值得信赖"的原因。敢于承认问题、严谨修复，比宣称"没有问题"更有底气。零缺陷是"审"出来的，不是"说"出来的。

五、创新：让财务"会思考"

这是最有创意的地方。我没有去接外部 AI API（受限于无密钥），而是自研了一个纯本地的财务数据规则引擎：

尤其要说红色呼吸灯这个设计——它把"风险警示"这个抽象概念，变成了用户一眼就能感知的视觉语言（box-shadow 明暗呼吸 + 图标脉冲）。好的交互设计，是把业务语义翻译成人的直觉。

创新不一定非要"外接大模型"。在有限条件下，用规则引擎把财务数据"激活"，做出决策、预警、交互，同样能带来 AI 感。

六、工程质量与部署

• 色彩语义化：借方绿、贷方青、期初黄，图表用帕累托/燃尽/双线折线等财务专业图形
• 4K 截图 + 博客发布：Playwright 拍 18 张 4K 图做抖音素材，技术博客发到主站
• 部署运维：Lighthouse + Nginx 反代 + systemd 自启，数据库重置一条命令

七、复盘：踩过的坑，也是收获

坑	教训
API 前缀双斜杠：//api/ 被解析成协议相对 URL	前端子路径部署时，API 基础路径必须动态计算，不能硬编码
刷新重新登录：token 存内存，刷新即丢	JWT 单页应用必须 localStorage 持久化 + restoreAuth 验证恢复
凭证号重复崩溃：补种子数据误插重复 → UNIQUE 冲突	财务系统的唯一性约束是保护伞

📌 写在最后

这套系统的成功，归结起来是四个字：扎实、创新。

扎实——需求吃透、架构先行、严谨兜底、安全审计、零缺陷验证，每一个环节都做足功课。创新——在有限条件下用规则引擎做出 AI 决策/预警/助手，用红色呼吸灯把风险可视化。

研发的世界里，没有捷径，但有方法。把业务规则研究透，把严谨写进架构，把用户体验做到细节，把质量验证做到极致——这就是一套系统"功底扎实又有创意"的根本原因。