多数数据库引擎不支持无引号中文别名，PostgreSQL/SQL Server/Oracle报语法错误，MySQL虽可运行但下游工具易乱码；ORDER BY部分支持双引号中文，GROUP BY完全不可用；安全方案是统一用英文小写下划线命名。
SQL字段别名用中文会触发哪些解析错误
多数数据库引擎在解析别名时，会把未加引号的中文直接当作非法标识符处理。比如 SELECT name AS 姓名 在 PostgreSQL 里报 syntax error at or near "姓名"，SQL Server 报 incorrect syntax near '姓名'；MySQL 虽然能跑通（依赖 sql_mode 设置），但一旦导出到 BI 工具或 ORM 映射层，姓名 往往变成乱码或空字段。
- PostgreSQL / SQL Server / Oracle：默认不支持无引号中文别名，必须写成
SELECT name AS "姓名" - MySQL：允许
SELECT name AS 姓名，但连接字符集为latin1时会截断或报错 - SQLite：支持双引号，但若应用层用 Python 的 sqlite3 模块，默认返回字典键是 bytes 类型，
row[b'\xe5\xa7\x93\xe5\x90\x8d']需手动 decode
下游系统根本“看不见”中文别名
报表工具（如 Tableau、Power BI）、ORM（如 Django ORM、SQLAlchemy）和大多数 HTTP API 序列化逻辑，都假设列名是 ASCII 字符。它们要么跳过非 ASCII 别名，要么用下划线自动替换（姓名 → _），要么直接抛 UnicodeEncodeError。这不是配置问题，是底层协议限制——JDBC/ODBC 驱动对列元数据的编码处理普遍不兼容 UTF-8 列名。
- Django 的
cursor.fetchall()返回 tuple，字段名存在cursor.description中，但很多旧版驱动把它当 Latin-1 解码 - Power BI 导入时若检测到中文列名，会静默重命名为
Column1、Column2，且不提示 - 前端 JavaScript 接口解析 JSON 时，若后端用中文 key（如
{"姓名": "张三"}），某些老旧 Axios 版本会因 header 编码问题丢弃该字段
别名含中文时 ORDER BY 和 GROUP BY 行为不可靠
即使你强行用双引号包住中文别名让 SELECT 过了，ORDER BY 也未必认。PostgreSQL 允许 ORDER BY "姓名"，但 SQL Server 要求双引号 + 全大写（ORDER BY "姓名" 报错，ORDER BY "XINGMING" 才行）；而 GROUP BY 根本不能用任何别名——它执行早于 SELECT，所以 GROUP BY "姓名" 在所有主流数据库里都报错，必须回退到原始表达式，比如 GROUP BY name。
- 别名只在 SELECT 和 ORDER BY（部分数据库）中有效，GROUP BY / HAVING / WHERE 绝对不可用
- 一旦用了中文别名，你就得在 ORDER BY 里重复写
"姓名"，在 GROUP BY 里却必须写name，混用极易出错 - 团队协作时，别人看到
ORDER BY "姓名"却找不到对应 SELECT 中的字段定义，因为编辑器语法高亮常把双引号内容当字符串忽略
真正安全又通用的替代方案
用英文小写下划线命名，不是为了“洋气”，而是绕开所有编码、驱动、协议、工具链的兼容性雷区。比如 SELECT user_name AS user_full_name，这个 user_full_name 能被 MySQL、PostgreSQL、Python、JavaScript、Excel 全部原样识别，不需要任何额外配置或转义。
- 优先使用业务语义清晰的英文：用
order_amount而不是amount，用created_at而不是time - 避免拼音：
yonghu_name比user_name更难维护，且无法被英文技术文档或日志系统索引 - 注释补足语义：在建表或视图 SQL 顶部加
-- 姓名 → user_full_name，既保可读性，又不污染运行时
中文别名看着省事，实际是把编码问题、工具链断裂、跨团队理解成本，全堆到运行时和调试阶段。真正麻烦的从来不是写几个英文单词，而是凌晨三点排查 BI 报表字段突然变空，却只因为某条 SQL 里写了 AS "总数"。
