SQL Server中字段名含空格必须用方括号[]包裹，如[username]，否则报错；方括号也适用于保留字、数字开头或特殊字符命名，是SQL Server唯一标准转义方式。

SQL Server 里用方括号包裹含空格或关键字的列名

SQL Server 不允许直接写 SELECT user name FROM users 这种带空格的字段名，会报错 Incorrect syntax near 'name'。必须用方括号 [user name] 显式标记标识符边界。

常见触发场景包括：字段名含空格、连字符、中文、以数字开头（如 2nd_score），或撞上保留字（如 order、desc）。方括号是 SQL Server 唯一标准方式，反引号在这里无效。

• 正确写法：SELECT [user name], [2nd_score], [order] FROM orders
• 嵌套使用也合法：SELECT [user].[name] FROM [dbo].[users]（表名和列名都可括）
• 注意：方括号不能嵌套，[[name]] 表示字面量 [name]，不是转义

MySQL 中反引号是唯一安全的字段名转义方式

MySQL 默认不认方括号，强行用会报错 You have an error in your SQL syntax。必须用反引号 ` 包裹特殊字段名，比如 `user name` 或 `order`。

反引号对所有非标准标识符都有效，包括含空格、点号、中文、保留字，甚至含反引号本身（需双写：`` 表示单个 ` 字符）。

• 正确写法：SELECT `user name`, `2nd_score`, `order` FROM `orders`
• 表名、数据库名同样需要：SELECT * FROM `my-db`.`user table`
• 如果启用了 ANSI_QUOTES SQL 模式，双引号也会被当作标识符分隔符，但默认不启用，别依赖

PostgreSQL 和 SQLite 怎么处理？别混用符号

PostgreSQL 只认双引号 "user name"，方括号和反引号都会报错；SQLite 则两者都支持——但反引号是 MySQL 兼容模式下的非标准扩展，不推荐在跨平台项目中用。

关键在于：不同数据库对“特殊字段名”的解析逻辑完全不同，没有通用转义符号。写死 ` 或 [] 的 SQL 很可能在换库时直接挂掉。

• PostgreSQL 正确：SELECT "user name", "order" FROM "users"
• SQLite 虽然接受 `user name`，但更建议统一用双引号保持与 PostgreSQL 兼容
• 如果用 ORM（如 SQLAlchemy、Django ORM），让框架生成带引号的 SQL，比手写更可靠

为什么加了括号还是报错？检查这三处

加了 [...] 或 `...` 还报错，大概率不是转义问题，而是底层逻辑错误。

• 字段名拼写大小写不一致：SQL Server 默认不区分，但启用了区分大小写的排序规则（如 _CS 后缀）时，[UserName] ≠ [username]
• 字段根本不存在：括号只解决语法解析，不解决语义错误；先查 INFORMATION_SCHEMA.COLUMNS 确认字段真实存在
• 权限不足：用户无权访问该字段（尤其启用了行级或列级安全策略时），错误可能表现为“无效列名”，实为权限拦截

真正容易被忽略的是：字段名里混入不可见字符（如零宽空格、BOM），看着像 name，实际是 name\u200b，括号也救不了——得用 HEX() 或直接重命名字段来排查。