pg-format客户端Sanitizing对比预编译语句的劣势有哪些？

除了你提到的执行相似查询时的性能劣势，用pg-format这类客户端格式化库替代参数化预编译语句还有以下几个关键劣势：

• 人为失误导致的SQL注入风险无法根除
  尽管pg-format宣称使用正确的格式化标记（如%L用于字符串、%I用于标识符）能保证安全，但开发过程中很容易出现疏漏——比如误将%L写成普通字符串拼接、忘记对动态标识符使用%I、或者在复杂逻辑中混合了手动拼接与格式化。这类错误很难通过静态代码检测发现，一旦出现就会直接引入SQL注入漏洞，而参数化预编译语句从机制上分离了SQL模板与参数，从根源上避免了这类风险。

• 数据库执行计划复用受限
  参数化预编译语句的SQL模板是固定的，数据库可以缓存其执行计划，后续相同模板的查询直接复用优化后的计划。但pg-format每次生成的是包含具体参数的完整SQL字符串，即使逻辑相同，只要参数不同，SQL文本就有差异，数据库无法复用执行计划。这不仅会增加查询的CPU开销（优化器需反复生成计划），还可能导致复杂查询的执行计划不稳定，出现性能波动。

• 缺乏类型安全保障
  参数化预编译语句会自动处理编程语言类型与数据库类型的转换（比如将日期对象、数值类型转换为数据库兼容的格式），避免了类型不匹配导致的语法错误或数据失真。而pg-format依赖开发者手动处理类型转换：比如将数字转成字符串时可能出现精度丢失、日期转字符串时不符合PostgreSQL的格式要求，这类问题只会在运行时暴露，排查成本更高。

• 跨数据库兼容性差
  pg-format是针对PostgreSQL设计的格式化工具，其标记规则（如%I处理标识符）仅适用于PG语法。如果后续需要迁移到其他数据库（如MySQL、SQL Server），则需要替换为对应的客户端格式化库，同时修改所有格式化代码。而参数化预编译语句是数据库驱动的标准特性，跨数据库时只需调整SQL模板的语法细节，无需改动参数传递的逻辑。

• 调试与运维成本提升
  虽然pg-format能在客户端记录完整的SQL语句，但当参数包含特殊字符（如单引号、换行符）时，生成的SQL会变得难以阅读和调试。而参数化预编译语句的调试可以分开查看SQL模板和对应的参数值，更容易定位问题。此外，在数据库审计日志中，参数化查询会保留模板结构，而pg-format生成的SQL会混杂参数值，不利于分析查询模式和排查异常。

• 权限控制粒度被弱化
  参数化预编译语句可以配合数据库的细粒度权限控制：比如可以限制用户只能执行特定的预编译语句，缩小权限范围。但pg-format生成的是动态SQL，用户需要拥有执行所有可能生成的SQL的权限，这扩大了权限边界，一旦出现漏洞，攻击者能利用的操作范围更广。

内容的提问来源于stack exchange，提问作者nzn