先确认系统是否已生成en_us.utf-8：运行locale -a | grep -i en_us.utf-8，有输出才表示支持；若无输出，需先通过dpkg-reconfigure locales（debian/ubuntu）、dnf reinstall glibc-langpack-en（rhel/centos 8+）或编辑/etc/locale.gen后执行locale-gen（arch等）生成该locale。
LANG=en_US.UTF-8 不生效，大概率不是写错了配置，而是系统压根没生成这个 locale。
怎么确认 en_US.UTF-8 已被系统支持
直接 export LANG=en_US.UTF-8 后运行 locale，如果看到 locale: Cannot set LC_CTYPE to default locale: No such file or directory 这类警告，说明 locale 数据缺失。
必须先验证是否已生成：
- 运行
locale -a | grep -i en_us.utf-8—— 有输出才表示可用 - 无输出时，Debian/Ubuntu 系统执行
sudo dpkg-reconfigure locales，勾选en_US.UTF-8 - RHEL/CentOS 8+ 执行
sudo dnf reinstall glibc-langpack-en - Arch 系需编辑
/etc/locale.gen，取消注释en_US.UTF-8 UTF-8行，再跑sudo locale-gen
/etc/default/locale vs /etc/locale.conf vs /etc/sysconfig/i18n 写哪？
写错位置等于白改，不同发行版读取逻辑完全不同：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- Debian/Ubuntu：只认
/etc/default/locale，格式必须是LANG="en_US.UTF-8"（带双引号） - RHEL/CentOS 7+/Fedora/Arch：用
/etc/locale.conf，格式为LANG=en_US.UTF-8（无引号，单行） - RHEL/CentOS 6 及更老系统：走
/etc/sysconfig/i18n，同样写LANG="en_US.UTF-8" - 桌面环境（GNOME/KDE）可能缓存旧值，改完必须登出重进，或执行
sudo systemctl restart systemd-localed
为什么 SSH 登录后又变中文？LC_ALL 和 PAM 是关键
即使全局配置正确，SSH 会话仍可能回退，常见原因有两个：
-
LC_ALL非空：它会强制覆盖所有LC_*和LANG。检查locale输出中LC_ALL是否为空；不为空就unset LC_ALL或统一设为en_US.UTF-8 - PAM 覆盖：
/etc/pam.d/sshd若加载了pam_env.so，且/etc/security/pam_env.conf里硬编码了中文，你的 shell 配置就无效 - SSH 客户端也可能传入
AcceptEnv LANG LC_*，临时解决可在~/.bashrc末尾加export LANG=en_US.UTF-8，并确保它在 source 链靠后
localectl set-locale 在 RHEL/Fedora 上最省事
Red Hat 系用户别手动改文件，localectl 是 systemd 提供的权威接口，自动处理配置、同步、服务重启：
- 执行
sudo localectl set-locale LANG=en_US.UTF-8 - 立即生效，新启动的 shell 会话自动继承
- 验证用
localectl status，比看locale更可靠——它显示的是系统级实际应用的值 - 注意：该命令不会生成 locale，仍需先确认
en_US.UTF-8已存在（见第一个副标题）
最容易被忽略的是：改完配置不检查 LC_ALL，也不验证 locale -a 是否真有对应条目。很多“设置失败”其实卡在第一步——系统根本没这个 locale 数据，后续所有操作都是空中楼阁。
