直接拼接sql字符串会触发sql注入，因为用户输入被当作sql代码执行而非数据；参数化查询通过预编译分离结构与数据，强制输入仅为值，需同时满足声明占位符、设类型、赋value值三条件才生效。

为什么直接拼接SQL字符串会触发SQL注入

Delphi里用 TADOQuery 时，如果写成 ADOQuery1.SQL.Text := 'SELECT * FROM users WHERE name = ''' + Edit1.Text + '''';，攻击者输入 O'Reilly'; DROP TABLE users; -- 就能执行任意语句。根本原因是字符串拼接把用户输入当成了SQL代码的一部分，数据库引擎不区分“数据”和“指令”。

参数化查询强制把输入当作纯数据处理，数据库预编译时就固定了语句结构，后续只填充值，不会重新解析语法。

正确使用Parameters对象的三步操作

必须同时满足三个条件才真正生效：声明参数占位符、设置参数类型、赋值。漏掉任一环都可能退化为拼接行为或报错。

• SQL文本中用 : 开头命名参数（如 WHERE name = :user_name），不能用 @ 或 ?
• 调用 Parameters.ParamByName('user_name').DataType := ftString; 显式指定类型，避免隐式转换失败
• 赋值必须用 .Value 属性（Parameters.ParamByName('user_name').Value := Edit1.Text;），不能用 .AsString 等子属性——后者在参数未初始化时会触发访问异常

ftWideString 和 ftString 的实际区别在哪

Delphi 2009+ 默认使用 Unicode 字符串，但 SQL Server 的 varchar 列对应 ftString，nvarchar 才对应 ftWideString。混用会导致乱码或截断，尤其处理中文时。

PaperXie智能写作

PaperXie智能写作是一款AI论文写作工具，AI学术写作辅助工具，覆盖全流程服务。

下载

常见错误是全部用 ftString，结果 SQL Server 把传入的 Unicode 字符按单字节截断；或者全用 ftWideString，连接旧版 Access 数据库时报“类型不匹配”。

• 查 varchar / char 字段 → 用 ftString
• 查 nvarchar / nchar 字段 → 用 ftWideString
• 不确定时，先用 ADOConnection.GetFieldNames 查表结构确认字段类型

动态SQL中参数名重复或缺失的典型报错

运行时报 Parameter 'xxx' not found，大概率是 SQL 文本里写了 :user_id，但代码里调用了 ParamByName('userid')（少下划线）；或者 SQL 里参数名大小写不一致（虽然 ADO 通常不敏感，但某些驱动版本会校验）。

更隐蔽的问题是循环中反复调用 Parameters.Clear 后没重设类型，导致第二次执行时参数类型丢失，数值类参数（如 ftInteger）传入空字符串会抛出类型转换异常。

• 参数名严格保持大小写和拼写一致，建议全小写加下划线
• 避免在循环里调用 Clear，改用 ParamByName('x').Value := newValue 覆盖赋值
• 调试时用 ADOQuery1.Parameters.Count 和 Parameters[i].Name 检查实际加载的参数列表

参数绑定不是加个冒号就完事，关键在类型匹配和生命周期管理。最容易被忽略的是：SQL Server 连接字符串里 Provider=SQLOLEDB 时默认禁用 Unicode 参数，必须显式加 UseUnicode=True，否则 ftWideString 仍会降级为 ANSI。