最稳方案是直接读/sys/class/power_supply/，因其不依赖D-Bus、upower服务或ACPI，绕过unknown状态，适配银河麒麟、UOS及轻量环境；需动态遍历目录并容错读取capacity、status等字段。
直接读 /sys/class/power_supply/ 是最稳的方案，不依赖服务、不挑发行版、不卡在 Wayland 或 minimal systemd 环境里。其他工具如 upower 或 acpi 容易返回 unknown 或静默失败，尤其在银河麒麟、统信UOS、轻量容器或老旧 BIOS 设备上。
为什么 upower -i 经常显示 state: unknown
upower 依赖 D-Bus 和后台的 upower 服务进程。该服务在以下情况会不可用：
- 用户级
systemctl --user is-active upower返回inactive（常见于无桌面环境或 SSH 登录会话） - 系统级服务被禁用：
sudo systemctl is-active upower为failed或not-found - 内核未加载对应电池驱动，或 ACPI 表缺失
_BIF/_BST方法（ARM 设备、Surface Pro X、部分国产笔记本） - 设备路径不是
BAT0，而是axp288_battery、battery或battery_0，但upower --enumerate没匹配到
此时强行启用服务（sudo systemctl enable --now upower）可能无效——某些嵌入式内核压根没编译 UPower 支持。
cat /sys/class/power_supply/*/capacity 怎么安全遍历
不能硬写死 BAT0，不同机器差异大。正确做法是动态探测：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 先列出所有候选：
ls /sys/class/power_supply/，关注含battery、BAT、axp的目录名 - 过滤掉
ACAD、usb等非电池设备：for d in /sys/class/power_supply/*; do [ -f "$d/capacity" ] && echo "$d"; done - 读关键字段时加容错：
cat /sys/class/power_supply/BAT0/status 2>/dev/null || echo "N/A"（避免因驱动未导出某字段而报错中断） - 健康度建议用
energy-full÷energy-full-design计算，比capacity字段更可靠（后者在部分驱动中只是回显 design 值）
acpi 和 inxi -b 的适用边界
acpi 是纯用户态解析器，严重依赖 BIOS 提供的 ACPI 表。一旦 BIOS 关闭电池支持或使用非标实现，就会输出 No support for device type: battery 或直接空行。它不适合写进自动化脚本。
inxi -b 虽然汇总友好，但底层仍调用 upower 或 acpi，且在无网络环境或未安装 inxi 的最小化系统中不可用。它的 condition 字段（如 52.2/53.2 Wh (98.0%)）本质也是从 energy-full 和 energy-full-design 推导而来——不如自己读 sysfs 直观可控。
真正容易被忽略的是电压老化判断：cat /sys/class/power_supply/BAT0/voltage_now 长期低于标称值（如锂电标称 11.1V，实测常压仅 10.2V），比百分比更能反映电池衰减。这个字段不被多数工具展示，但 sysfs 始终可用。
