lshw 是生产环境获取完整硬件清单最可靠的工具，需 root 权限运行，支持 JSON 和 HTML 输出，避免使用 -short，跨架构时需结合 lspci 补充识别。
用 lshw 一次性导出完整硬件清单最可靠
生产环境要准确拿到 CPU 型号、内存插槽数量、磁盘型号与拓扑、网卡驱动版本等真实规格，lshw 是目前最接近“开箱即用”的工具。它直接读取 sysfs 和 DMI 数据，不依赖用户态模拟或猜测，比拼凑 cat /proc/cpuinfo + dmidecode + lsblk 更少出错。
注意：需 root 权限运行，普通用户只能看到降级信息（如无内存插槽细节、无固件版本）。
-
sudo lshw -json -quiet输出结构化 JSON，适合后续解析（如用jq提取特定字段） -
sudo lshw -html > hardware.html生成带折叠树的本地 HTML，运维人工核查最直观 - 避免用
-short，它会丢掉关键字段如serial、firmware、slot - 某些 ARM 服务器或老内核（lspci -vvv 单独存档
收集前必须检查 dmidecode 是否可用且权限正确
lshw 依赖 DMI/SMBIOS 表获取主板、内存条、BIOS 版本等核心信息。如果 dmidecode 不在 PATH 或被 SELinux/udev 规则拦截，lshw 就会静默降级——比如显示 “memory” 节点但所有 size 为 0，或 firmware 字段为空。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 先执行
sudo dmidecode -t system | head -5确认能输出非空内容 - 若报错
Permission denied，不是权限不够，而是 BIOS 锁定了 DMI 访问（常见于某些 Dell PowerEdge 的 Secure Boot 模式），需进 BIOS 关闭 “DMI Lock” 或 “System Information Lock” 选项 - 若报错
No SMBIOS nor DMI entry point found，说明虚拟机未透传 DMI 表（如 KVM 启动时没加-smbios参数），此时只能靠lscpu、lsmem、smartctl -i等分项补全
脚本里别硬编码路径，用 which + command -v 做存在性兜底
生产服务器 OS 差异大：CentOS 7 默认没装 lshw，Ubuntu 可能装在 /usr/bin/lshw，而某些定制系统把它编译到 /opt/tools/bin/lshw。脚本一上来就 lshw -json 报 command not found，整条链就断了。
- 用
cmd_lshw=$(command -v lshw)获取实际路径，再判断[ -x "$cmd_lshw" ] - 缺失时自动尝试安装：
apt-get install -y lshw（Debian/Ubuntu）或yum install -y lshw（RHEL/CentOS），但需提前确认包管理器可用 - 不要用
which替代command -v，前者在某些 shell（如 dash）中不可靠，且不处理 alias - 收集结果文件名建议含主机名和时间戳：
hardware_$(hostname -s)_$(date +%Y%m%d_%H%M%S).json
远程批量采集时，ssh 连接参数和错误捕获不能省
用 for host in ${HOSTS[@]}; do ssh $host 'sudo lshw -json'; done 看似简单，实际会卡在密码输入、tty 分配失败、超时中断上，导致部分机器漏采或脚本挂起。
- 强制分配伪终端会干扰 JSON 输出，必须加
-T（禁用 tty） - 设置连接超时：
ssh -o ConnectTimeout=10 -o BatchMode=yes -T $host ...，避免因网络抖动卡死 - 用
set -e+||显式捕获错误：if ! output=$($ssh_cmd 2>&1); then echo "[$host] failed: $output" >&2; continue; fi - 敏感环境慎用密钥免密登录；若必须用，确保私钥权限是
600，否则 ssh 直接拒绝加载
真正麻烦的是跨架构兼容——ARM 服务器上 lshw 可能不识别某些 PCIe 加速卡的 vendor ID，这时候得靠 lspci -n 查原始 device ID，再查 PCI ID 数据库手动补注。这种边界情况没法全自动，得在脚本日志里留明确标记。
