watch并非实时监听而是周期轮询，其“看到变化”的效果取决于命令选择、刷新间隔与输出稳定性；-d高亮仅比对纯文本差异，遇时间戳、动态截取或未引号包裹的管道即失效。
watch 不是实时监听，而是按秒轮询；想“看到变化”，关键在选对命令、设对间隔、避开输出干扰
watch -d 高亮没反应？检查输出是否含动态字段
watch -d 只比对两次输出的**纯文本差异**，不是语义变化。以下情况会让高亮失效：
- 命令含
date、uptime、top -b等自带时间戳或滚动内容的输出 → 每次全屏变，高亮失去意义 - 用了
tail -n 20这类动态截取 → 行序滑动导致差异位置飘移 - 管道没用单引号包裹，比如
watch -d ps aux | grep nginx→ 实际只对ps aux高亮，grep在 watch 外执行 - 命令输出含 ANSI 转义序列（如带颜色的
ls --color）→ 必须加-c才能正确识别颜色差异
监控文件数量时，find 和 ls 哪个更准
统计“文件数”不能只靠 ls -A | wc -l，它把目录、符号链接、设备文件全算进去。真要盯普通文件数量，用 find 更可靠：
-
find . -maxdepth 1 -type f | wc -l：只计当前目录下的普通文件（不含子目录，不含隐藏目录如.git） - 要排除隐藏文件，加
-not -path "./.*"：如find . -maxdepth 1 -not -path "./.*" -type f | wc -l - 统计特定后缀（如
.log），用-name "*.log"；忽略大小写用-iname - 注意
-maxdepth 1必须放在-name和-type前，否则被忽略
刷新太频繁反而卡顿？别硬设 -n 0.5
watch 本身不耗资源，但所执行的命令会。以下设置容易翻车：
-
-n 0.1或-n 0.5配合ps aux、df -h等 → 短时间内大量 fork 子进程，CPU 占用飙升 -
ls -lR或深度find / -name "*.tmp"→ I/O 暴涨，可能拖慢整个系统 - 终端宽度未适配就跑
ps aux→ 输出换行错乱，watch标题栏进一步挤压可视区 - 解决办法：
watch -t -n 2 'ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -12'，去标题 + 限字段 + 限行数
退出后发现进程还在跑？Ctrl+C 不等于 killall
watch 被 Ctrl+C 中断后，它 fork 出的子命令（尤其是带 &、tail -f、ping 的）可能仍在后台运行：
- 先用
ps aux | grep "your_command"确认残留进程 - 用
kill或pkill -f "your_command"清理 - 长期监控建议改用
inotifywait（事件驱动）或写脚本加trap 'kill $(jobs -p) 2>/dev/null' EXIT - 临时防残留：避免在 watch 命令里直接用
&或后台作业符
真正难的不是敲出那条 watch 命令，而是想清楚你到底想“看什么变化”——是数值增减？文件出现？还是某字段突变？选错命令或参数，再高频刷新也只是刷屏而已。
