GROUP_CONCAT中文乱码或截断的根本原因是连接层字符集非utf8mb4及group_concat_max_len过小；需确保character_set_client/connection/results均为utf8mb4，并调大group_concat_max_len至足够字节数。
GROUP_CONCAT 返回中文变成问号或乱码
根本原因是 GROUP_CONCAT 的结果默认继承连接层的字符集，而连接层若没设为 utf8mb4，哪怕字段本身是 utf8mb4，拼接后也会退化成 latin1 或截断。典型现象：单条查正常，GROUP_CONCAT 一用就变 ???? 或 Mojibake。
- 执行
SHOW VARIABLES LIKE 'character_set%';，确认character_set_client、character_set_connection、character_set_results全部是utf8mb4；任一不是，GROUP_CONCAT就可能出问题 - 不要依赖建库/建表时的默认字符集——
GROUP_CONCAT不读字段定义，它只看当前 session 的连接字符集 - 临时修复可在查询前加：
SET NAMES utf8mb4;，但更可靠的是在连接初始化时就固定（如 PDO DSN 加charset=utf8mb4）
GROUP_CONCAT 中文被截断或长度不够
GROUP_CONCAT 默认最大长度是 1024 字节（不是字符），且按字节计算。UTF-8 下一个中文占 3 字节，utf8mb4 下可能占 4 字节（如 emoji），所以实际能拼的中文远少于 1024 个。
- 查当前限制：
SHOW VARIABLES LIKE 'group_concat_max_len'; - 临时调高（当前 session 有效）：
SET SESSION group_concat_max_len = 1000000; - 永久生效需改 MySQL 配置文件（
my.cnf或my.ini），在[mysqld]段下加：group_concat_max_len = 1000000 - 注意：这个值单位是字节，不是字符；如果拼接内容含 emoji 或生僻字，建议预留 4×预期字符数的空间
CONVERT + CAST 强制转码仍无效？检查隐式转换链
有人试过 CONVERT(GROUP_CONCAT(name) USING utf8mb4) 还是乱码，问题往往出在“转换发生在拼接之后”，而拼接过程本身已损坏——GROUP_CONCAT 内部先用错误字符集做了 concat，再 convert 已无力回天。
- 正确做法是让 concat 过程就在正确字符集下运行：
GROUP_CONCAT(CONVERT(name USING utf8mb4)) - 更稳妥写法（兼容字段本身字符集不一致的情况）：
GROUP_CONCAT(CAST(name AS CHAR CHARACTER SET utf8mb4)) - 如果字段是
latin1存的旧数据，不能只靠CONVERT补救，得先确认原始字节是否真能映射为有效 UTF-8，否则会得到 符号
ORDER BY 在 GROUP_CONCAT 里失效或排序错乱
常见写法 GROUP_CONCAT(name ORDER BY id) 看似没问题，但一旦涉及中文，排序行为可能不符合预期——因为排序依据的是字段的 collation，不是字符集。
- 确认字段 collation 是支持中文比较的，比如
utf8mb4_unicode_ci或utf8mb4_zh_0900_as_cs（MySQL 8.0+） - 如果字段是
utf8mb4_general_ci，对中文排序基本等同于按字节序，不可靠 - 强制指定排序规则：
GROUP_CONCAT(name ORDER BY name COLLATE utf8mb4_unicode_ci) - 注意：
ORDER BY子句里不能用别名，也不能用函数表达式（如UPPER(name)），否则会报错或静默忽略
最易被忽略的一点：GROUP_CONCAT 的字符集行为完全独立于字段定义和表结构，它只认连接层设置 + 显式类型转换。线上出问题时，别急着改表，先查 character_set_connection 和 group_concat_max_len，90% 的 case 都卡在这两个地方。
