健康度必须用 energy-full ÷ energy-full-design × 100% 计算，因 upower 的 capacity 字段在部分系统中为缓存值，不可靠；最稳方式是直读 /sys/class/power_supply/bat0/ 下的 energy_full 和 energy_full_design（或 charge_full 等）原始值。
Linux 下不能直接用一个命令输出“健康度 XX%”——必须自己算，而且得先确认数据来源是否可靠。
为什么 upower 的 capacity 字段不能直接信
很多教程说 upower -i /org/freedesktop/UPower/devices/battery_BAT0 里 capacity: 82.3% 就是健康度，但这个值在部分系统（尤其是银河麒麟、某些 OEM 定制内核）中是硬编码或缓存值，不随实际 energy-full 变化更新。实测中出现过 capacity 停留在 95% 多天，而 energy-full 已从 56Wh 掉到 48Wh 的情况。
- 它只是个快捷字段，不是实时计算结果
- 若
upower服务未运行或权限不足，该字段会显示unknown - 真正可信的是
energy-full和energy-full-design这两个原始值
最稳的方式：直读 /sys/class/power_supply/ 目录
这是 Linux 内核暴露的底层接口，不依赖 D-Bus、不依赖 upower 服务，几乎所有笔记本（包括 ARM 设备如树莓派 CM4 笔记本）都支持。路径可能为 BAT0、BAT1、axp288_battery 或 bq27541-0，先确认：
ls /sys/class/power_supply/
然后读取关键文件（单位是微瓦时 µWh）：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
cat /sys/class/power_supply/BAT0/energy_full_design→ 出厂设计容量 -
cat /sys/class/power_supply/BAT0/energy_full→ 当前满充容量（放完再充满后最准） - 若报
No such file or directory，尝试charge_full_design和charge_full（单位是 µAh） - 健康度 =
energy_full ÷ energy_full_design × 100%；损耗率 =100% − 健康度
银河麒麟等国产系统要额外注意 gsettings 备份路径
银河麒麟（基于 Ubuntu/Debian）的 UKUI 桌面会把电池容量缓存在 dconf 后端，有时比 sysfs 更“平滑”，适合交叉验证：
-
gsettings get org.ukui.power-manager battery-design-capacity→ 返回类似56.0（单位 Wh） -
gsettings get org.ukui.power-manager battery-full-capacity→ 返回类似43.8 - 注意：这两个值是浮点数，需手动计算，且只在 GNOME/UKUI 环境下写入，重启后可能滞后
- 如果和 sysfs 结果差超 3%，说明驱动或固件有采样偏差，应以 sysfs 为准
tlp 的 Health 值看起来很专业，但别当真
sudo tlp-stat -b 输出里的 Health: 94% 是综合了循环次数、温度、电压衰减模型的估算值，不是实测容量比。它的作用是预警，不是计量：
- 循环次数（
Charge cycle count）超过 500 次后，Health会加速下降，但此时真实容量可能还有 85%+ - 同一块电池，在低温环境运行一天后，
Health可能临时掉到 89%，回暖后又回升——这不代表物理老化 - 它不替代容量比值，只作补充参考
真正影响你续航的，永远是 energy-full / energy-full-design 这个比值。其他所有字段，都是围绕它做的包装或推测。
