smartctl -H 返回 PASSED 并不绝对安全，因该结果仅基于少数阈值判断，无法反映SSD早期磨损、备用块耗尽等隐患；真实风险需通过smartctl -A查看Percentage Used（NVMe）或Media_Wearout_Indicator（SATA SSD）等关键属性。
smartctl -H 返回 PASSED 就安全？别信
很多用户看到 smartctl -H /dev/nvme0n1 输出 PASSED 就放下心，这是最危险的误判。SMART 整体健康评估只看几个关键阈值是否越界，而 SSD 的早期磨损、备用块耗尽、接口错误等根本不会触发它。真实风险藏在具体属性里，比如 Percentage Used（NVMe）或 Media_Wearout_Indicator（SATA SSD），这些值一旦接近 100%，即使 -H 还是 PASSED，也该立刻安排数据迁移。
SSD 关键属性怎么看：NVMe 和 SATA 完全不同
SSD 厂商对 SMART 属性命名不统一，必须按接口类型区分查看方式：
- NVMe 盘（如
/dev/nvme0n1）用sudo smartctl -A /dev/nvme0n1，重点盯：Percentage Used（已用寿命百分比）、Available Spare（剩余备用块比例）、Available Spare Threshold（触发警告的下限） - SATA SSD（如
/dev/sda）用同样命令，但关注：Media_Wearout_Indicator（越小越糟，典型安全值 >1）、Reallocated_Sector_Ct（非零即警讯）、Uncorrect（不可纠正错误数） - 别看
Raw_Read_Error_Rate或Seek_Error_Rate—— 这些在 SSD 上无意义，数值受固件编码影响，跨盘不可比
执行自检前必须确认三件事
smartctl -t long 对 SSD 来说不是“慢”，而是可能干扰控制器后台任务，尤其在高负载时引发 I/O 卡顿甚至写入延迟飙升。执行前务必确认：
- 目标设备未被
dd、rsync、数据库进程直接读写（否则报Device or resource busy） - 不是系统根盘且未挂载为
/或/boot（部分 NVMe 驱动在自检中会短暂冻结队列） - 先运行
smartctl -c /dev/nvme0n1看是否支持long自检；老旧 USB-SATA 转接器或某些 PCIe 拓展卡常直接拒绝该命令
检测中用 smartctl -l selftest /dev/nvme0n1 查状态，结果不会自动落日志，必须手动提取。
发现 “FAILING_NOW” 或 “Pre-fail” 属性就停手
在 smartctl -A 输出里，如果任意一行的 WHEN_FAILED 列显示 FAILING_NOW 或 Pre-fail，说明该属性已跌破厂商硬阈值，硬盘处于故障临界点。此时：
- 立即停止写入，避免触发更多重映射或耗尽备用块
- 用
dd if=/dev/zero of=/tmp/test bs=1M count=100快速验证写入是否稳定（若报 I/O 错误，基本可判定失效） - 不要依赖
smartctl -X中断自检——它对 NVMe 无效，有些 SATA SSD 也不响应
真正可靠的预警不是某次命令的结果，而是连续几天观察 Percentage Used 或 Available Spare 的变化趋势。跳变 2% 以上，就得当回事。
