用 FireDAC 写稳定 SQL：参数化、事务边界与连接复用
2026/07/06
FireDAC 的基础能力很成熟，但真正把项目写稳，靠的不是“能查出结果”，而是参数化、事务边界和连接使用习惯能不能始终一致。这篇是我自己的实践总结。
FireDAC 我用得越久，越觉得它的问题从来不在“功能够不够”，而在“团队会不会把它用乱”。很多 Delphi 项目刚开始都挺顺，拖几个组件、写几条 SQL、马上能出结果。问题是这种写法只要持续几个月，后面很容易变成到处散落查询、事务边界混乱、连接状态也没人说得清。
我现在最看重的其实就三件事：参数化是不是默认动作，事务边界是不是清楚，连接是不是被稳定地管理。只要这三件事做得随意，系统迟早会开始出现偶发错误，而且往往不是一眼能看出来的问题。比如某次保存成功、某次保存半截失败，或者列表偶尔能查出来、偶尔条件不准，这类问题排查起来特别耗精力。
参数化这件事我现在基本不谈“建议”，而是当作底线。不是为了写法好看，而是因为只要还在手工拼条件，迟早会遇到引号、日期格式、空值、模糊匹配或者注入风险。很多人觉得自己做的是桌面程序，不对外暴露，就容易放松警惕，但只要数据来自用户输入，参数化就不该是可选项。
事务也一样。
真正难的不是会不会写
StartTransaction，而是你是否清楚哪些操作必须成组成功、哪些允许局部失败、哪些异常要回滚。很多业务 bug 表面上像逻辑错误，本质上其实是事务边界没划清，导致数据库状态处于半完成状态。
至于连接管理，我现在越来越不喜欢那种“哪个地方要查就顺手开一个组件”的写法。小项目还能忍，大一点的系统很快就会失控。 我的习惯是把连接生命周期和使用场景对应清楚，至少要让人看代码时知道：这个查询为什么在这里执行，它依赖哪个连接，它跟别的操作是不是同一事务。
FireDAC 真正能不能把项目托稳，不取决于组件面板有多方便，而取决于你有没有一套始终一致的 SQL 使用规则。把这件事收紧，后面的维护成本会差很多。