uname -m 是最直接反映系统原生架构的命令，输出 x86_64 或 aarch64 表示 64 位，i386、i686、armv7l 表示 32 位；它读取内核启动时声明的 ABI 架构，不随容器、chroot 或兼容模式变化，也不依赖用户空间配置，因此比 getconf LONG_BIT 更可靠地标识系统真实架构。
uname -m 是最直接反映系统原生架构的命令，输出 x86_64 或 aarch64 表示 64 位，i386、i686、armv7l 表示 32 位。它读取内核启动时声明的 ABI 架构，不随容器、chroot 或兼容模式变化，也不依赖用户空间配置。
为什么优先信 uname -m 而不是 getconf LONG_BIT
因为 getconf LONG_BIT 只告诉你当前 shell 进程的指针宽度，容易被误导：
- 在 64 位内核上运行 32 位 chroot 环境时，getconf LONG_BIT 返回 32，但系统本身仍是 x86_64
- Docker 官方镜像如 debian:stable-slim 可能是 32 位用户空间，getconf LONG_BIT 显示 32，而宿主机 uname -m 仍是 x86_64
- setarch i386 bash 启动的 shell 会让 getconf LONG_BIT 返回 32，但内核和系统 ABI 没变
所以它适合查“当前进程跑在哪种 ABI 下”，不适合查“系统是什么架构”
file /sbin/init 用来验证实际可执行环境
当 uname -m 和 getconf LONG_BIT 不一致，或你怀疑混用多架构二进制时，就该看真实 ELF 文件：
- 执行 file /sbin/init，重点看开头的 ELF 64-bit 或 ELF 32-bit —— 中间的 “64-bit”/“32-bit” 才是关键
- 如果 /sbin/init 是符号链接（比如指向 /lib/systemd/systemd）或不存在（Alpine 常用 /init），退而求其次查 file /bin/ls
- 注意：如果输出含 cannot open 或 data，说明文件被 strip 过或根本不是 ELF（例如是脚本），该方法失效
别被 /proc/cpuinfo 的 lm 标志带偏
grep lm /proc/cpuinfo 有输出，只代表 CPU 支持 long mode（即能执行 64 位指令），不代表当前系统就是 64 位：
- 常见情况：CPU 支持 lm，但装了 32 位内核，uname -m 仍为 i686
- 没有 lm，基本可断定是纯 32 位 CPU（如老 Pentium M），系统必为 32 位
- ARM 平台不用纠结这个：只要 uname -m 是 aarch64 就是 64 位，armv7l 就是 32 位，/proc/cpuinfo 不提供等价标志
真正决定软件能否安装、ABI 是否统一的，是 uname -m 输出的值。其他命令只是辅助验证——尤其在容器、嵌入式或定制系统里，一个字段偏差就可能导致 apt install 报错或 gcc 编译出错。
