lang环境变量直接修改几乎无效，主因是系统未生成对应locale、配置文件路径/格式错误或被lc_all覆盖；须先用locale -a验证zh_cn.utf-8或en_us.utf-8是否存在，再依发行版生成并写入正确配置文件，同时清除lc_all干扰。
LANG 环境变量几乎从不生效——系统没生成对应 locale、写错配置文件路径、被 LC_ALL 覆盖，三者占了 90% 的失败原因。
先确认 zh_CN.UTF-8 或 en_US.UTF-8 是否真实存在
很多用户一上来就编辑配置文件，结果重启后还是乱码，根本原因是系统压根没这个 locale。
- 运行
locale -a | grep -i "zh_cn\|en_us"，看输出里有没有zh_CN.UTF-8或en_US.UTF-8 - 没输出？说明必须先生成：Debian/Ubuntu 执行
sudo dpkg-reconfigure locales，空格选中目标项后 OK；CentOS/RHEL 8+ 运行sudo dnf reinstall glibc-langpack-zh（中文）或glibc-langpack-en（英文）；Arch 用户需编辑/etc/locale.gen取消注释对应行，再跑sudo locale-gen - 注意大小写和点号：
zh_CN.utf8≠zh_CN.UTF-8，现代发行版默认要求大写 UTF-8，老系统可能只认小写
写对配置文件位置和格式
不同发行版读取的主配置文件完全不同，写错路径等于白改，且不会报错。
- Debian/Ubuntu：优先读
/etc/default/locale，内容为LANG="zh_CN.UTF-8"（带双引号） - RHEL/CentOS 7+/Fedora/Arch：用
sudo localectl set-locale LANG=zh_CN.UTF-8（无引号），它会自动写入/etc/locale.conf - RHEL 6 及更老系统：必须改
/etc/sysconfig/i18n，格式同上，但拼错路径（比如/etc/syscnfig/i18n）很常见
检查并清空 LC_ALL
LC_ALL 是最高优先级的 locale 变量，只要它非空，LANG 和其他 LC_* 全部失效——这是切语言后仍乱码或静默无效的最隐蔽原因。
- 运行
locale，如果LC_ALL有值（比如LC_ALL=zh_CN.UTF-8），就说明它在起作用 - 临时解决：
unset LC_ALL或export LC_ALL=（空值） - 永久清理：检查
/etc/environment、/etc/profile.d/*.sh、用户级的~/.bashrc或~/.profile，删掉或注释掉export LC_ALL=...这类行 - SSH 登录时尤其要注意：客户端可能通过
AcceptEnv LANG LC_*把旧值带进来，可临时在服务端/etc/ssh/sshd_config中注释该行并重启sshd
终端和字体不配合，locale 再对也白搭
即使 locale 显示全绿、echo "你好" 正常，图形界面菜单或终端里仍是方块，问题一定出在字体或终端编码上。
- 终端本身要设 UTF-8 编码：Xshell/FinalShell 需手动设 Remote character set 为 UTF-8；Windows 自带 OpenSSH 则需提前运行
chcp 65001 - 字体得支持对应语言：运行
fc-list :lang=zh应有输出；没有就装fonts-wqy-microhei（Debian/Ubuntu）或wqy-microhei-fonts（RHEL/CentOS） - 桌面环境（GNOME/KDE）还会缓存旧设置，改完必须登出重进，不能只重启终端
LC_ALL 没清、终端编码没调、字体没装这四点中的某一个，而且它们之间互不报错，只能靠 locale、locale -a、env | grep LC 一层层剥。
