最可靠方法是运行 uname -m：i386/i686 为 32 位，x86_64/aarch64 为 64 位；getconf LONG_BIT 等命令仅反映当前进程位数，易受兼容模式误导，不能代表系统原生架构。
怎么看当前 Linux 是 32 位还是 64 位系统
直接看 uname -m 输出最可靠，它反映内核运行的架构，不是安装包或用户空间的“感觉”。i386、i686 表示 32 位；x86_64 表示 64 位；aarch64 是 ARM 64 位；armv7l 通常是 32 位 ARM。
常见错误是只查 getconf LONG_BIT —— 它返回的是当前 shell 进程的指针宽度（即运行时位数），如果在 32 位兼容模式下跑 64 位系统，结果会误导你。比如在某些容器或 chroot 环境里，getconf LONG_BIT 可能返回 32，但宿主机仍是 x86_64。
-
uname -m看内核原生架构，优先用这个 -
arch是uname -m的别名，效果一样 - 避免只依赖
file /sbin/init或file /bin/bash，二进制可能是多架构编译或被替换过 - 在 WSL1 或旧版虚拟机里，
uname -m有时会伪装成x86_64，需结合cat /proc/cpuinfo | grep flags看有没有lm（long mode）标志
为什么 dpkg --print-architecture 和 rpm -q --queryformat '%{ARCH}\n' glibc 结果可能不一致
这两个命令查的是“软件包管理器默认安装的架构”，不是系统能力。Debian/Ubuntu 默认设为 amd64 即使你装了 i386 多架构支持；RHEL/CentOS 下 glibc 架构可能只是主安装包的，不代表内核或 CPU 能力。
典型场景：你在 Ubuntu 上执行 sudo dpkg --add-architecture i386 后，dpkg --print-architecture 仍返回 amd64，但你能装 32 位库——这说明系统支持多架构，不是“系统变成 32 位”了。
-
dpkg --print-architecture是 APT 的默认目标架构，和/etc/dpkg/dpkg.cfg.d/multiarch配置有关 -
rpm -q --queryformat '%{ARCH}' glibc查的是 glibc 包本身编译时的目标，不是运行时能力 - 真正决定能否运行某程序的是
uname -m+ CPU 支持 + 内核配置（如是否禁用了 IA32_EMULATION）
file /sbin/init 显示 ELF 64-bit，但系统跑着 32 位应用？怎么回事
因为 init 进程只是第一个用户态进程，它的位数只说明它自己是 64 位编译的，并不约束其他进程。Linux 内核（尤其是 x86_64）默认开启 IA32_EMULATION，允许直接加载和运行 32 位 ELF，无需模拟器。
容易踩的坑是看到 file /bin/ls 是 32 位，就以为系统是 32 位——其实只要内核支持，64 位系统完全可以混跑 32 位程序，甚至通过 setarch i386 强制以 32 位 ABI 启动。
- 检查内核是否启用 32 位兼容：
grep CONFIG_IA32_EMULATION /boot/config-$(uname -r)，输出CONFIG_IA32_EMULATION=y才行 -
setarch i386 bash可临时进入 32 位环境，getconf LONG_BIT在里面会返回 32 - 某些精简发行版（如 Alpine）或容器镜像可能关闭该选项，此时 32 位程序会报
Exec format error
ARM 设备上 uname -m 返回 aarch64 还是 armv7l 怎么判断
这取决于 CPU 实际运行的执行状态和内核编译选项，不是单纯看芯片型号。例如树莓派 4B 的 CPU 支持 aarch64，但如果刷的是 32 位 Raspbian 系统，内核就是 armv7l；反过来，用 64 位 Raspberry Pi OS，uname -m 就是 aarch64。
关键点在于：ARMv8 芯片可以运行在 AArch32（32 位）或 AArch64（64 位）模式，两者互不兼容，切换需要重启并换内核镜像。
- 不要只看
cat /proc/cpuinfo | grep Model，Model name 是厂商字符串，不反映当前运行模式 -
lscpu | grep "Architecture"更直观，但底层仍依赖uname -m - ARM64 系统无法运行原生 ARM32 内核模块，即使用户空间有 32 位 libc；反之亦然
- 某些国产 ARM 板（如飞腾）可能把
loongarch64或riscv64当作uname -m输出，它们和 x86_64 完全不兼容
位数不是非黑即白的标签，而是内核、CPU、工具链、用户空间四层对齐的结果。最容易忽略的是：同一台机器上，uname -m 固定，但 getconf LONG_BIT 和 file 输出可随进程变化——别用一个命令的结果去断言整个系统的“类型”。
