$lang是事实上的主控变量，决定终端解析和显示字节的编码；只要未被lc_all或lc_ctype显式覆盖，所有locale行为均按$lang执行，其值末尾的utf-8即当前生效编码。
$LANG 是最直接有效的判断依据，不是“之一”，而是事实上的主控变量。 它决定了终端实际用什么编码解析和显示字节，绝大多数场景下查它就够了，不用绕路。
为什么直接看 $LANG 就行
Linux 终端的字符渲染行为由 locale 系统驱动，而 LANG 是 fallback 基准：只要没被 LC_ALL 或 LC_CTYPE 显式覆盖，所有 locale 相关行为（包括中文、emoji、宽字符宽度）都按 LANG 的值执行。
-
echo $LANG输出如en_US.UTF-8或zh_CN.UTF-8，末尾的UTF-8就是当前生效的字符编码 - 如果输出为空或
C，说明终端处于 ASCII 模式，非 ASCII 字符（比如中文）会显示为方框或问号 -
locale命令输出虽全，但容易干扰判断——比如LC_ALL=""（空字符串）会让整块输出变成一堆C，但$LANG仍可能有效
LC_CTYPE 和 LC_ALL 怎么影响实际结果
真正控制字符分类、大小写转换、宽字符显示的是 LC_CTYPE；而 LC_ALL 是最高优先级开关，一旦设为非空值（哪怕只是 LC_ALL=），它就强制覆盖 LANG 和所有 LC_* 变量。
- 优先检查：
locale | grep -E "(LANG|LC_CTYPE|LC_ALL)"—— 这三行能快速定位谁在起作用 - 如果
LC_CTYPE已设置（如LC_CTYPE="zh_CN.GB18030"），它比$LANG优先 - 如果
LC_ALL非空（比如LC_ALL=POSIX），那LANG和LC_CTYPE全部失效 - 特别注意：
LC_ALL=""（空字符串）比设成C更隐蔽——它不报错，但会让所有 locale 行为退化，且难以察觉
别把终端编码和文件编码混成一回事
终端字符编码只管“怎么显示字节”，文件本身有独立编码。两者不匹配，cat 一打开就是乱码。
- 查文件真实编码用：
file -i filename或chardet filename - 比如一个
GBK编码的文本，在$LANG=en_US.UTF-8终端里cat出来是乱码，这不是终端错了，是解码方式不匹配 - 临时适配可改终端：
export LANG=zh_CN.GB18030；但真正修复应转码文件：iconv -f GBK -t UTF-8 filename > newfile - /etc/locale.conf 或 ~/.bashrc 里的设置只对新启动的 shell 生效，已运行的终端 session 不会自动 reload
最容易被忽略的其实是 LC_ALL="" 这种状态——它既不报错也不提示，却让整个 locale 系统静默退化，查 $LANG 看着正常，实际行为已经不对了。
