Linux系统实际生效的字符集由LC_CTYPE环境变量决定，而非LANG；若LC_CTYPE为空或为C/POSIX，则中文必乱码，且须确保其值（如zh_CN.UTF-8）已通过locale-gen生成并存在于locale -a输出中。
Linux系统没有一个全局统一的“默认字符集”概念，真正起作用的是 locale 环境变量组合，其中 LC_CTYPE 决定字符编码行为，LANG 是它的兜底值。直接看 locale 命令输出里的 LC_CTYPE 行，就是当前 shell 解释文本时实际用的字符集。
查当前生效的字符集（别只看 LANG）
locale 输出中，LC_CTYPE 的值才是程序判断字节流是否合法、如何显示中文/emoji 的依据。如果它为空或未设置，才会 fallback 到 LANG。常见误区是只改了 LANG 却忽略 LC_CTYPE，结果 ls 显示中文文件名仍乱码。
- 运行
locale，重点检查LC_CTYPE="en_US.UTF-8"这类行，不是只看第一行LANG - 若输出含
LC_CTYPE="C"或LC_CTYPE="POSIX"，说明字符处理退化为 ASCII，中文必然乱码 - 用
locale -a | grep -i utf-8确认系统已生成目标 locale（如zh_CN.UTF-8），否则后续设置无效
locale: Cannot set LC_CTYPE to default locale 错误怎么修
这个警告本质是：你设置了 LANG=zh_CN.UTF-8，但系统根本没生成过 zh_CN.UTF-8 这个 locale 实例，glibc 加载失败。
- 先执行
locale -a | grep zh_CN，如果无输出，说明 locale 未生成 - 编辑
/etc/locale.gen，取消对应行注释，例如去掉# zh_CN.UTF-8 UTF-8前的# - 运行
sudo locale-gen编译生成（Debian/Ubuntu）；RHEL/CentOS 用sudo localectl set-locale LANG=zh_CN.UTF-8会自动触发生成 - 生成后重启终端或执行
source /etc/default/locale（Debian/Ubuntu）或localectl status（RHEL）验证
永久修改要分发行版，不能通用一套命令
Ubuntu/Debian 和 RHEL/CentOS/Fedora 的配置机制不同，混用会导致设置不生效或被覆盖。
- Ubuntu/Debian：写入
/etc/default/locale，内容为LANG="zh_CN.UTF-8"，无需设LC_ALL（它会压制所有LC_*） - RHEL/CentOS/Fedora：用
localectl set-locale LANG=zh_CN.UTF-8，它会自动更新/etc/locale.conf并通知 systemd - 用户级临时设置：在
~/.bashrc或~/.zshrc里加export LANG=zh_CN.UTF-8，然后source，但注意这不会影响 systemd 服务或 GUI 应用 - 绝对不要在
/etc/profile里硬写export LC_ALL=...—— 它会让排序、日期等全部按 C 规则走，中文排序变成乱序
MySQL/Python/VSCode 乱码不是 locale 问题？
很多用户以为终端 locale 改了，MySQL 就能存中文，Python 就能读文件不报 UnicodeDecodeError，其实不是一回事。
- MySQL 字符集由
character_set_server、数据库/表/列的CHARACTER SET共同决定，和系统 locale 无关；查用SHOW VARIABLES LIKE 'character_set%'; - Python 3 默认用 UTF-8，但打开文件时若没指定
encoding参数，会依赖locale.getpreferredencoding()—— 这个值才受系统 locale 影响 - VSCode 的文件编码由编辑器自身控制（右下角点击切换），和系统 locale 无关；但终端集成（Integrated Terminal）的显示效果，取决于 shell 的
LC_CTYPE
最易被忽略的点：locale 配置必须「生成 + 设置」两步都完成，缺一不可；且 LC_CTYPE 的值必须真实存在于 locale -a 输出中，否则所有基于 glibc 的程序（包括 bash、ls、grep）都会静默 fallback 到 C locale，导致中文显示、正则匹配、大小写转换全部异常。
