我有个朋友，干了十几年后端开发，最近被一个需求整得焦头烂额。他们公司要做个内部用的数据看板，功能不复杂，就是几个图表加实时刷新。按常规思路，得搭个后端服务，写接口，做鉴权，再配个缓存层。可他嫌麻烦，直接让前端用数据库连接串连上了 MySQL。结果上线没两天，数据库 CPU 飙到 80%，连接数爆表，几个核心业务表被锁死，整个系统差点瘫痪。这事儿让我想起一个老生常谈的话题——客户端直连数据库，这个看似简单的捷径背后，到底藏着多少坑？
先说说它为什么诱人。直连数据库最大的好处就是省事。对小型项目、原型验证或者内部工具来说，后端这层中间件确实有点多余。想象一下，一个团队小到只有两三个人，产品还在试错阶段，上来就搞微服务、API 网关、权限中心，这不成杀鸡用牛刀了吗？直连模式能大幅缩短开发周期，你把 SQL 写在前端，后端都不用写一行代码。另外，对某些实时性要求极高的场景，比如游戏排行榜、实时监控面板，少一层中间件就意味着少一次网络开销，延迟能降几毫秒。这种情况下，直连确实有它的合理性。
但千万别被表面的甜头迷了眼。直连数据库最致命的隐患是安全。你把数据库的账号密码直接放在前端代码里，不管是写在 JavaScript 文件里，还是藏在某个配置里，本质上就是把大门钥匙挂在门外。稍微有点技术底子的用户，打开浏览器的开发者工具，翻翻网络请求，就能看到明文密码。就算用了加密，只要客户端能解密，黑客也能。更别提 SQL 注入攻击了，前端传进来的参数如果不做严格校验，一条恶意 SQL 就能把用户表、订单表全删光。这不是危言耸听，每年因为直连数据库导致的数据泄露事件数不胜数。
再聊聊性能问题。数据库的设计初衷是持久化存储，不是给成千上万个客户端同时当查询服务器用的。每个数据库连接都是资源，连接池再多也有限。当几百个浏览器窗口同时打开，每个都维持一个长连接，数据库的连接数很快就会撑爆。更麻烦的是，前端开发者往往不太懂 SQL 优化。他们可能随手写个 ，这种嵌套子查询在百万级数据量下，能把数据库拖到怀疑人生。而中间件层可以帮你做连接复用、请求合并、缓存热点数据，这些能力是直连模式完全做不到的。
还有一个容易被忽视的问题——版本兼容和升级。数据库是个活物，版本在迭代，SQL 语法在变，连接驱动也在更新。如果前端直连了数据库，哪天 DBA 说要把 MySQL 从 5.7 升到 8.0，或者把 PostgreSQL 从 12 升到 15，前端代码可能就得跟着改。更糟的是，不同版本的客户端使用不同版本的驱动库，旧语法在新版本里被废弃，应用就会莫名其妙报错。而中间件层像个适配器，帮你屏蔽底层差异，升级数据库对业务代码几乎无感。
那是不是说直连模式就一无是处？也不是。对某些特定场景，它反而是最优解。比如嵌入式设备上的本地数据库，像 SQLite，客户端直连就是标准做法。再比如一些严格的内网环境，所有客户端都在同一个安全域内，没有外部攻击风险，而且数据量不大、并发不高，直连确实能省下服务器成本。还有游戏开发中，很多单机或局域网游戏直接使用 SQLite 或轻量级数据库，这也是合理的。关键在于要清楚自己的场景属于哪一类，别把内网的经验直接套到公网。
我见过一个更极端的例子。有个做物联网的公司，他们的设备端直接连了云数据库，结果某个设备固件有 bug，每隔几秒就发一条查询，把数据库打到完全不可用。排查时发现，那个设备居然用了 root 账号直连。这不是技术问题，而是架构思维的问题。直连模式把数据库暴露给了最不可控的客户端环境，而中间件层恰恰像一个守门人，能帮你做流量整形、熔断降级、错误隔离。没有这层保护，数据库就像裸奔在互联网上。
话说回来，如果你实在要选择直连，也不是完全没有办法。至少要做几件事：使用只读账号，权限精细到表级甚至字段级；把 IP 白名单写死，只允许特定网段访问；对每个查询设置超时限制，防止慢查询拖垮数据库；定期审计 SQL 日志，关注异常请求。但这些防护措施说白了都是在打补丁，只能降低风险，不能消除风险。真正的安全架构应该是“默认不信任”，而不是“默认信任然后加锁”。
说说我的看法。客户端直连数据库，就像在高速公路上开卡丁车——刺激是真刺激，但出事也是真快。对原型验证、内部工具、低并发内网应用，它是个不错的快速方案。但一旦要面对真实用户、处理敏感数据，或者有高并发需求，老老实实加一层中间件吧。这层中间件可以是简单的 API 网关，也可以是 GraphQL 服务，甚至是一层代理。它带来的开发成本和性能损耗，远小于一次数据泄露或全站宕机的代价。做技术选型时，别光盯着“方便”两个字，多想想“万一出事怎么办”。毕竟，数据库是你的核心资产，不是能随便裸奔的东西。
