做过财务系统开发的朋友都知道，凭证附件是整个系统里不能出错的核心模块。每一张记账凭证背后，都对应着发票、报销单、合同这些原始凭证，要么是扫描件要么是拍照导出的电子文件，少则几兆多则几十上百兆，存储方案选不对，后期系统维护能把人折腾到崩溃。
不少刚入行的开发图省事儿，直接把文件转成二进制存在数据库里，上线前几个月用着好像没啥问题，等凭证量上来，数据库体积直接飙到几百G，备份慢、查询慢，连正常的结账对账都卡。
还有人选了文件服务器，看似解决了体积问题，结果时间长了附件丢了、文件路径对不上，查账的时候找不到原始凭证，直接捅出合规性大篓子。
很多人觉得存在数据库是懒人才选的方案，其实真不是，这个方案也有它不可替代的优势。
最大的好处就是数据一致性和完整性好保证。财务数据讲究的就是账实对应，凭证记录和附件存在同一个库，只要事务做对了，要么同时成功要么同时失败，不会出现凭证做了，附件没存进去的情况。备份也方便，一个数据库备份文件就把所有数据都带走了，不用分开备份数据库和文件目录，恢复的时候一步就能搞定，不会漏东西。
而且安全性也更好控制，数据库本身就有权限校验，文件内容不会随便被外部访问，不用担心服务器上的附件被人直接爬走，对于要符合《会计档案管理办法》要求的财务系统来说，这点真的很省心。
但缺点同样戳痛点，数据库性能会被活活拖垮。普通的财务凭证记录也就几百字节，一个附件就是几M，每次查询凭证都要把二进制内容读出来，数据库缓存根本放不下这么大的内容，IO开销直接拉满，并发稍微高一点，整个系统就卡得动不了。
迁移更是噩梦，数据库扩容的时候，几G的表导出导入都要等大半天，几百G的附件库，迁移一次要熬好几个通宵。就算你用的是现在流行的云数据库，超出存储容量的成本也比单独买文件存储贵不少，长期用下来成本涨得飞快。
现在大部分成熟的财务系统，都把附件存在文件服务器或者对象存储里，数据库只存文件路径和哈希值，这个方案确实解决了数据库的性能问题。
最直接的好处就是不影响核心业务的性能，数据库只存元数据，体积小查询快，不管存多少附件，凭证查询、记账结账这些核心操作都不会卡，对用户来说体验好太多。存储扩容也简单，文件服务器不够用了直接加硬盘，对象存储更是按需扩容，不用动核心数据库，成本比存数据库低一大截。
而且文件管理更灵活，你要给下载附件做限速，要给不同公司的附件做存储隔离，要做CDN加速让异地的用户下载更快，这些操作都能在文件层面做，不用改数据库的配置，后期迭代很方便。
但坑也不少，最麻烦就是一致性很难保证。你想啊，业务流程是先存文件到文件服务器，再把路径写到数据库，如果存完文件网络断了，数据库没写上，就成了孤儿文件，占存储空间还没用。反过来如果数据库先写了路径，文件没存成功，就成了有凭证没附件的烂账，查账的时候直接出问题。
还有文件命名和路径维护的麻烦，时间长了服务器搬迁，或者存储路径改了，所有凭证里存的路径都要改，漏改一个那个附件就废了。如果没做好文件的校验，磁盘坏道或者存储节点出问题，直接就丢了附件，财务丢原始凭证可是大事故。
没有绝对完美的方案，只有适合你系统场景的选择。
如果你的是小微型企业的本地财务系统，凭证量不多，一年下来也就几千上万张凭证，附件总容量不会超过几十个G，其实存在数据库完全没问题，维护起来简单，不用管两套存储，对小企业来说运维成本低才是最重要的。
如果你的是多租户的SaaS财务系统，或者要服务中大型企业，凭证量一年几十万上百万张，那必须选文件服务器+数据库存元数据的方案，哪怕要处理一致性问题，也比后期数据库崩了强。
现在其实还有更折中的方案，小附件存数据库，大附件存文件服务器。比如几k几十k的电子回单存数据库，超过1M的合同、扫描件存文件服务器，既保证了小附件的一致性，又不会把数据库撑大，很多成熟的财务系统都是这么干的。
不管选哪种，一定要做文件的校验和多备份，存数据库要定期做一致性校验，存文件服务器要给文件加哈希校验，同时做多副本备份，毕竟财务凭证要保存十几年甚至更久，数据不丢才是第一位的。
很多人纠结哪个方案更技术先进，其实对财务系统来说，符合监管要求、数据不丢、用着稳定，比什么花里胡哨的技术都重要。你之前踩过凭证附件存储的坑吗，可以留言说说你的经历。
