活动监视器“磁盘”页仅显示瞬时写入速率，无法反映SSD真实损耗；须用smartctl定期读取Data Units Written累计值和Percentage Used（逼近80%需警惕），配合launchd自动化监控与DriveDx/SMART Utility辅助分析。
直接看“活动监视器”里的“磁盘”标签页，就能实时看到当前每秒写入量（KB/s 或 MB/s），但这个数字不累计、不区分进程写入类型，仅作即时参考；真要保护 SSD 寿命，必须结合 smartctl 定期读取 Data Units Written 累计值，并关注 Percentage Used 是否逼近 80%。
活动监视器只能看瞬时写入速率，不能反映 SSD 真实损耗
“活动监视器”→“磁盘”页显示的 Write 列是操作系统层统计的每秒写入字节数，它包含大量缓存、日志、临时文件等非持久化写入。APFS 的延迟写入和内存 pageout 机制会让这个数字远高于实际落盘量。
- 该数值会随 Spotlight 索引、Time Machine 本地快照、系统日志轮转剧烈波动，不能用于评估 TBW 消耗趋势
- 看不到哪个进程在持续刷盘（比如某个 Electron 应用后台写日志），需配合
sudo fs_usage -f filesys | grep 'write'追踪 - 程序坞图标只显示读/写方向脉冲，无量化数值，仅适合粗略感知磁盘是否“忙”
用 smartctl 定期抓取 Data Units Written 和 Percentage Used 才算数
smartctl 直读 NVMe Log Page 0x02，拿到的是 SSD 主控固件上报的原始累计写入量和寿命消耗百分比，这才是 Apple 官方不提供、但最接近真实损耗的指标。
- 先确认设备名：
diskutil list | grep "NVMe\|internal"，认准顶层disk0（不是disk0s1） - 执行：
sudo /usr/local/sbin/smartctl -a /dev/disk0，重点盯住两行：Data Units Written: XXX,XXX,XXX [YY.X TB]和Percentage Used: Z% - M1/M2/M3 Mac 必须启用 Rosetta 运行终端，否则
smartctl可能识别不到内置 NVMe 设备 - 别信
Estimated Lifetime Remaining—— Apple 未公开 TBW 值，这个推算结果纯属示意
自动化监控不能只靠手动跑命令
每天打开终端敲一遍 smartctl 不现实，必须用脚本+launchd 实现后台定时采集，否则等你发现 Percentage Used 跑到 85% 就晚了。
- 写个 Python 脚本定期调用
smartctl，提取Data Units Written和Percentage Used，追加写入/Users/Shared/DiskUsage.log - 创建
~/Library/LaunchAgents/com.user.diskmonitor.plist，设为每 6 小时运行一次，确保 macOS 启动后自动加载 - 脚本里加判断：若
Percentage Used > 80，用osascript -e 'display notification ...'弹窗提醒 - 避免用 cron —— macOS 13+ 对后台任务调度更严格，launchd 是唯一可靠选择
第三方 GUI 工具选 DriveDx 还是 SMART Utility？
DriveDx 解析原生 Log Page 0x02 最准，但必须手动开启「完整磁盘访问」权限，且 M 系列芯片上偶尔掉设备；SMART Utility 更轻量稳定，菜单栏常驻、支持自定义告警阈值（如 Percentage Used > 85 或 Temperature > 65），但对 Apple Silicon 内置 NVMe 支持略弱。
- 如果你只关心“现在还剩多少寿命”，用 DriveDx；它显示的
Percentage Used是固件直报，不是估算 - 如果你要长期盯温度+写入+备用块三要素，SMART Utility 的历史图表和告警更实用
- 两者都识别失败时，
smartctl是唯一兜底手段 —— 它不依赖图形权限，只要终端有 root 就能读寄存器
真正影响 SSD 寿命的不是某次大写入，而是长期小文件高频刷盘+高温叠加。监控本身不减损，但看不懂 Available Spare 连续两周掉超 3% 就去换盘，这种细节比“看一眼活动监视器”重要得多。
