QUOTENAME能防标识符注入是因为它将输入字符串转为带方括号的合法SQL标识符（如[user; DROP TABLE users--]），使SQL Server将其视为不可分割的名称而非可执行代码；它仅适用于表名、列名等标识符，不防SQL注入，也不能用于字符串字面量。
QUOTENAME 为什么能防标识符注入
因为 QUOTENAME 只处理字符串，把它转成带方括号的合法 SQL 标识符（比如把 user; DROP TABLE users-- 变成 [user; DROP TABLE users--]），SQL Server 在解析时会把它当做一个完整、不可分割的名称，不会执行其中的语句。
它不防 SQL 注入（比如值参数），只防标识符注入——也就是表名、列名、数据库名这类不能用参数化的地方。
- 只能用于标识符，不能用于字符串字面量（别拿它包
'admin'） - 默认用方括号
[]包裹，也可指定单引号'或双引号"，但 SQL Server 默认只认[]和""（需启用QUOTED_IDENTIFIER ON） - 内部会自动转义嵌套的右括号：把
abc]变成[abc]]，这是 SQL Server 的标准转义方式
QUOTENAME 在动态 SQL 中怎么用才安全
典型场景是拼接表名或列名。错误写法是直接拼接变量：EXEC('SELECT * FROM ' + @table_name) —— 这里 @table_name 一旦含恶意内容就崩了。
正确做法是先用 QUOTENAME 处理再拼接：
DECLARE @table_name NVARCHAR(128) = 'users; DROP TABLE logs--'; DECLARE @sql NVARCHAR(MAX) = 'SELECT TOP 1 * FROM ' + QUOTENAME(@table_name); EXEC sp_executesql @sql;
执行结果是查询 [users; DROP TABLE logs--] 这个“表”，而它大概率不存在，报错 Invalid object name '[users; DROP TABLE logs--]'，但至少没删库。
- 必须对每个动态拼入的标识符单独调用
QUOTENAME，包括数据库名、架构名、表名、列名 - 如果列名来自用户输入，也要
QUOTENAME(@column)，别只包表名 - 不要和字符串值混用：值要用
sp_executesql参数化，标识符才用QUOTENAME
QUOTENAME 的常见误用和坑
最常踩的坑是以为它能“消毒一切”。它不处理空字符串、NULL、超长名，也不校验标识符合法性（比如开头是数字），这些都得自己检查。
-
QUOTENAME(NULL)返回NULL，后续拼接会导致整个@sql变NULL，静默失败 -
QUOTENAME('')返回[]，这不是合法标识符，执行时报错Incorrect syntax near ']' - 输入超过 128 字符会被截断（
NVARCHAR(128)是 SQL Server 标识符长度上限），但函数不报错 - 不验证是否为保留关键字：
QUOTENAME('select')得到[select]，虽然能用，但容易引发可读性或维护问题
替代方案与边界情况
如果目标环境不是 SQL Server（比如 PostgreSQL、MySQL），QUOTENAME 不存在，得换方式：PostgreSQL 用 quote_ident()，MySQL 用反引号手动包裹（但无内置转义函数，得自己实现 ] → ]] 类逻辑）。
另外，某些极端场景下 QUOTENAME 也不够：比如动态生成带 schema 的三段式名称 [db].[schema].[table]，得分别对每段调用，再拼接，漏一段就可能出问题。
真正难的不是调用函数，而是判断哪些地方确实是标识符、哪些其实是数据值——这个边界模糊时，QUOTENAME 用错比不用还危险。
