less 和 more 的核心差异体现在导航、性能、搜索和管道支持：more 只能向前翻页，加载大文件慢，无交互搜索；less 支持双向滚动，按需加载性能优，内置搜索功能强，且在管道中可回溯，更适合大型文件和复杂操作。
less
和
more
是 linux/unix 系统里用来分页查看文本内容的两个核心工具。简单来说，它们能让你在终端里浏览那些屏幕装不下的大文件，而不是一股脑地把所有内容都刷出来，导致你错过开头。它们就像是文本文件的“阅读器”，让你能一页一页地看，控制阅读进度。
在我日常的工作流里，这两个命令出镜率极高，几乎成了反射弧的一部分。
more
算是老前辈了，它出现得更早，功能相对基础。你用
more filename
打开一个文件，它会从头开始显示，占满一屏后就停下来，等待你按空格键翻到下一页。如果你想退出，按
q
就行。但它的一个大痛点是，你只能往前翻，不能往回翻。一旦错过，或者想回顾一下前面看到的内容，对不起，你得重新打开文件。这在处理一些长日志，或者配置文件时，确实挺让人头疼的。
后来，
less
横空出世，一下子就把
more
甩开了好几条街。它的名字本身就很有趣，据说是因为它“more is less”（功能更多，但使用起来更轻松，或者说它能做
more
做不到的事）。
less
最核心的优势就是可以前后翻页，你可以用上下箭头、
PgUp
/
PgDn
，甚至
b
(backward) 和
f
(forward) 来回穿梭于文件内容之间。这在排查问题、对比配置的时候简直是救命稻草。而且，
less
在打开文件时并不会一次性加载整个文件到内存，而是按需加载，这对于查看超大型文件（比如几十GB的日志）来说，性能优势是压倒性的，几乎是秒开，不会卡顿。我记得有一次，我需要查看一个上百GB的mysql慢查询日志，
more
根本就没法用，而
less
却能轻松搞定，这体验上的差异，简直是天壤之别。
less和more命令的核心差异体现在哪些方面？
说到底，
less
和
more
的核心差异就像是“只读卷轴”和“可交互电子书”的区别。 最直观的，就是导航能力。
more
只能单向向前滚动，一旦内容滑过屏幕，就无法再返回。这就像看一部没有快退键的电影，错过就错过了。而
less
则支持双向滚动，你可以自由地向上、向下翻页，甚至像在文本编辑器里一样，用箭头键一行一行地移动。这种自由度在需要反复查阅、比对信息时，显得尤为重要。 其次是性能表现，尤其是在处理大型文件时。
more
在某些实现中可能会尝试加载更多的文件内容到内存，或者在启动时进行一些预处理，这对于超大文件来说，启动速度会很慢，甚至可能耗尽内存。
less
则采用了更智能的策略，它只加载当前需要显示的部分，当你滚动时再动态加载。这意味着无论文件有多大，
less
几乎都能瞬间打开，并且保持流畅的滚动体验。我个人经验是，当文件大小超过几十MB时，
less
的优势就非常明显了。 再来就是搜索功能。
less
内置了强大的搜索能力，你可以像在
vi
/
中一样，使用
/
字符进行向下搜索，使用
?
进行向上搜索，并通过
n
(next) 和
n
(previous) 在搜索结果之间跳转。这在日志文件中查找特定的错误信息或关键字时，简直是神器。
more
则不具备这样的交互式搜索能力，你可能需要结合
grep
才能实现类似的效果，但那终究不是同一个层级的体验。 最后，
less
对管道（pipe）的支持也更灵活。你经常会看到
command | less
这样的用法，它能让你方便地分页查看任何命令的输出。虽然
more
也能这么用，但
less
在管道中的表现，比如允许你返回查看之前输出的内容，无疑提供了更好的用户体验。
如何高效利用less命令进行文件内容检索与导航？
既然
less
如此强大，掌握它的快捷键和高级功能就显得尤为重要了。 在
less
界面里，最基础的导航操作包括：
- 空格键 (Spacebar) 或 f: 向下滚动一页。
- b: 向上滚动一页（back）。
- 回车键 (Enter) 或 j: 向下滚动一行。
- k: 向上滚动一行。
- d: 向下滚动半页。
- u: 向上滚动半页。
- g: 跳转到文件开头（go to beginning）。
- G: 跳转到文件末尾（go to end）。
- q: 退出
less
。
而真正让
less
脱颖而出的是它的搜索功能。
-
: 向下搜索指定的
/pattern
pattern
。例如，
会从当前位置向下查找第一个“error”。
-
: 向上搜索指定的
?pattern
pattern
。
-
: 跳转到下一个匹配项（next）。
n
-
: 跳转到上一个匹配项（previous）。
n
-
: 仅显示包含
&pattern
pattern
的行，隐藏其他行。这个功能在过滤大量无关信息时非常实用，比如
less access.log
后输入
&GET
就能只看 GET 请求的日志。要取消过滤，直接按
&
然后回车即可。
有时候，你可能想知道当前文件的大小或者当前位置的百分比，可以按
p
或
=
来查看。此外，
less
还可以打开多个文件，通过
:n
(next file) 和
:p
(previous file) 在它们之间切换，这在需要同时对比几个配置文件时非常方便。我个人就经常用
less file1 file2 file3
一次性打开好几个文件，然后快速切换查看。
在处理大型日志文件或实时数据流时，less和more各自的适用场景是什么？
在处理大型日志文件和实时数据流时，
less
和
more
的选择确实有讲究，虽然
less
大部分时候都是更好的选择，但
more
也有它特定的“舒适区”。 对于大型日志文件（比如几百MB到几十GB），毫无疑问，
less
是王者。它的按需加载机制保证了无论文件多大，都能秒开且流畅操作。你可以快速搜索错误码、用户ID，或者特定时间范围的日志。比如，
less /var/log/syslog
然后用
/error
搜索，效率极高。更进一步，结合管道，你可以先用
grep
过滤出感兴趣的行，再用
less
分页查看，例如
grep "failed login" /var/log/auth.log | less
。这种组合拳在故障排查中屡试不爽。
然而，
more
在处理实时数据流（比如
tail -f
的输出）时，就显得有些力不从心了，因为它不具备“跟随”文件末尾的功能。但有时候，如果你只是想快速瞥一眼某个命令的短暂输出，并且不打算来回翻页，
more
也能胜任，甚至因为它更简单，启动速度可能略快那么一点点（虽然在现代系统上这个差异几乎可以忽略不计）。比如
ls -l /usr/bin | more
，如果你只是想看一眼列表，不深究，也未尝不可。
不过，对于实时监控，我们通常会用到
tail -f
。如果你想对
tail -f
的输出进行分页和搜索，就不能直接用
more
了，但
less
有一个很棒的选项：
less +F
。这个命令会像
tail -f
一样，自动滚动到文件末尾并持续显示新内容。当你需要暂停查看、搜索历史内容时，只需按
Ctrl+c
暂停自动滚动，然后就可以像平时一样在
less
中前后翻页、搜索了。需要继续实时跟踪时，再按
f
键即可。这个
+F
模式，在我看来，几乎完美解决了实时日志查看和历史回溯的矛盾，让
less
在处理各种文件查看场景时都游刃有余。
总的来说，虽然
more
依然存在，但
less
的功能丰富性、性能优势以及用户体验，使得它成为了现代 Linux 系统中查看文件的首选工具。我个人几乎已经完全转向了
less
，除非是在一些非常老旧或者资源极度受限的环境下，才会偶尔想起
more
。
less
带来的效率提升，是实实在在的。
评论（已关闭）
评论已关闭