我一直在用 both 的时候周围就有同事问我这俩到底有啥区别我每次都是随便选一个用感觉都差不多。说实话如果你只是偶尔进个日志文件翻翻可能真感觉不到区别。但当你在生产环境排查一个几 GB 的日志或者写脚本处理文本流的时候选错命令就真的会“卡”到你怀疑人生。这篇东西我不会去抄 man page就围绕大家最关心的几个点来聊more 和 less 的核心能力差异、在管道和日志场景下的真实表现、以及我这些年实际使用中总结出的效率和踩坑经验。我会尽量把命令演示和背后的工作原理都说清楚让你读完就知道什么场景该用哪个并且能避开我当初踩过的那些坑。1. 这俩命令的“出身”和设计哲学差异为什么会有 two 个功能类似的工具先来点背景这有助于理解它们后续所有的行为差异。more 的诞生时间非常早是 BSD 系统里的老牌工具它的名字已经说明了它的设计逻辑就是“再多给我一屏”give me more。在那个终端还比较原始、内存资源也紧张的时代more 的设计目标非常朴素把一个比较长的文本一屏一屏地显示出来看完一屏按空格再往下看仅此而已。而 less 呢是 1983 年到 1985 年间由 Mark Nudelman 写的。它的名字很有意思它是一种反讽式的命名——“less is more”少即是多但实际功能却比 more 多了太多了。less 的口号也就是“opposite of more”。它的出现其实是为了突破 more 的种种局限尤其是 backwards往回翻、search搜索这些在 more 里不太好用或者压根没有的能力。所以你可以这样理解more 的设计哲学是“够用就好”它的代码体量和内存占用都非常小行为非常直接而 less 的设计哲学是“在终端里塞进一个完整的文本查看器”它要提供接近 Vim 那样强大的浏览和搜索体验但比 Vim 简单多了不需要记住一堆编辑命令。这个设计哲学的差异直接导致了一个很核心的区别more 通常只能向前翻少部分实现支持向后一点点less 则可以随便前后翻而且翻页极其流畅。很多刚从 Windows 过来、或者新手教程只教了 more 的运维朋友第一次用 less 第一次按上下箭头能往上翻时都会有一种“这才是人用的工具”的感觉。从技术实现角度再拆细一点两者的底层处理逻辑也不一样。more 的经典实现是读取文件内容后放到缓冲区然后按终端高度输出整个过程中交互状态相对简单。less 则维护了一个更复杂的缓冲区状态它需要支持行号跟踪、搜索高亮、多文件切换、标记位置等高级功能所以它在启动时可能会花更多内存来处理大文件但也正是这份内存换来了无比流畅的回滚和搜索体验。注意这里说的技术实现是基于我这些年使用 GNU 工具链和主流 BSD 系统的经验归纳的不同发行版或 Unix 系统里的 more / less 版本行为会有细微差异。比如在部分 Solaris 上more 的向后翻支持就很弱而 Linux 上很多发行版已经把 more 指向了 util-linux 的实现能力会强一些。但不管具体实现怎样more 整体上仍是“简化版”less 是“增强版”这条主线没有变。2. 分屏与回卷能力实测为什么说 less 是“可以直接淘汰 more”的第一步我第一次意识到这俩命令是“两个时代的产品”是在一次排查线上日志的时候。当时日志疯狂输出我习惯性地敲了more app.log结果发现日志刷得太快我根本来不及看而且当我试着按上箭头想回退看刚才的报错时屏幕上毫无反应。那一刻我很崩溃因为我记得当时用 less 是能回滚的。也是从那次起我彻底转投 less 阵营再也没用 more 看过超过一屏的文件。在分屏和回卷这块我做了一组对比测试大家可以直接抄作业操作more 的表现less 的表现查看下一屏空格键非常顺手空格键或 f 键、Ctrl-F查看上一屏大多数版本不支持部分版本如 util-linux 的 more支持 b 键但行为比较蹩脚直接按 b 键或 Ctrl-B非常流畅向下逐行滚动只有回车键逐行向下且频率很慢直接按 j 键或向下箭头连续滚动非常顺滑向上逐行滚动无除非是较新的实现比如部分发行版的 more 支持方向键但我遇到过的更多是不支持或体验极差直接按 k 键或向上箭头跳转到文件开头/结尾无g 跳到开头G 跳到结尾查找关键字支持/keyword但是不支持高亮或者高亮效果非常一般支持/keyword并且高亮命中n/N 循环跳转从这个表格能看出来more 的设计目标是“给你看完下一页”less 的设计目标却是“让你随心所欲地在文本里漫游”。如果你平时需要查看的文本都在一屏以内比如ls -l输出几乎不超过一屏那用 more 还是 less 确实无所谓。但只要文件一长、需要反复上下对比着看less 的体验优势就立刻体现出来了。所以我在工作里的习惯是只要内容可能超过一屏我 100% 用 less因为我不想为了 more 的那一点点内存占用省事而浪费我的时间。这里还有一个大家容易忽略的细节是less 支持按百分比定位。你打开一个日志文件后想快速看 50% 的位置直接按50%先输入数字 50再按百分号就能直接过去这在分析几万行的日志时非常有用。more 里虽然也有类似“跳到指定行”的命令格式通过行号启动但交互式地在文件内部跳转就没有 less 这么方便了。3. 搜索与高亮机制排查日志时这就是天壤之别分析日志、查报错、核对关键字是做运维和开发的日常。在这个场景下more 和 less 的差距可以说是天壤之别。我记得我初学 Linux 的时候用 more 查看日志发现有 ERROR 字样第一反应是“哦我看到了一处我按空格往下翻慢慢找”。那时候不懂事不知道还有什么搜索功能纯靠肉眼硬翻。直到后来有人告诉我less 里输入/ERROR回车所有匹配的 ERROR 都会高亮按 n 直接跳到下一个我的效率瞬间提升了一个档次。但搜索这件事也不能只看高亮less 的强大在于搜索状态的管理。比如搜索后跳转在 less 中输入/关键字回车后会自动跳到第一个匹配的位置按n继续下一个按N回退上一个。反向搜索按?关键字就能从当前位置向上搜索这在日志特别长、你刚才看到一处但现在想再往上看时非常实用。高亮记忆只要你不清空搜索高亮匹配的内容会一直高亮显示即使你前后翻了很久高亮依然有效。而 more同时支持/搜索是有的但高亮基本聊胜于无。搜索的模式less 默认是区分大小写的但你可以用-i参数启动或者直接搜索时用/关键字/i的语法来忽略大小写。这对查日志里大小写不规则的英文非常实用。对比 more 的搜索我结合实测经验来说more 在多数实现里支持/关键词搜索但搜索结果只是定位没有高亮而且它只会往当前位置之后找找到后不能通过 n/N 继续循环查找。部分系统的 more例如 util-linux 版本其实也支持 n/N 循环搜索但很多老 Unix 系统或精简环境里的 more 反而没有这个功能。所以如果你在脚本或者在线排查中不确定环境里的 more 具体是哪个版本和实现最好别依赖它的搜索循环能力用一个可以直接依赖的 less 会稳妥得多。还有一个可以明显提升效率的点less 支持搜索时的正则式。比如我经常在日志里找多个关键字的组合就直接用/(ERROR|FATAL|Exception)这样的正则表达式一下能命中所有相关异常。这在 more 里就很难实现。对于分析日志来说这种“一次命中多个模式”的能力真的太重要了。在这里附上一个我个人的避坑经验如果你用 less 搜索后发现匹配项没有高亮先检查一下是不是设置了-G去掉高亮之类的参数或者你的 TERM 环境变量有问题。有时候在 tmux 或 screen 会话里less 的高亮会因终端的 terminfo 配置而失效。可以用TERMxterm-256color来重新设置后再打开 less通常能解决。4. 性能与大文件表现为什么看超大的日志我更推荐 less有人可能会想more 更轻量看大文件是不是 more 更快更稳我的实测结论是事情没这么简单。more 在打开超大文件时确实启动极快因为它可能压根没有建立全套的行索引结构整体内存占用也更低。但这种低内存换来的后果是当你尝试在 more 里做“向上回卷”时部分实现会把你打回原形或者完全不响应或者重新从文件头开始再走一遍那个体验真的可以用灾难来形容。less 呢启动时会做更多初始化比如建立缓冲区映射和行状态信息。所以单纯看“打开文件”这个动作less 可能比 more 慢那么一会儿其实对于机械盘时代的旧版本慢得明显现在固态硬盘时代几乎感觉不到。但一旦文件打开之后来回翻页、搜索、跳转less 都要高效得多尤其是在配合-S参数处理长行日志时。说到长行日志这一点值得单独拎出来讲。很多业务日志是单行很长的 JSON 或带堆栈的文本若不处理当作普通文本打开会被自动折行wrap看起来非常乱。more 和 less 都有处理方式但我不太用 more 来做这种场景因为它的控制选项不够细。less 可以用-S参数让超长行不折行而是横向滚动显示这样日志里的字段结构就一目了然了。在 more 里虽然也有类似的控制能力但总体上没有 less 的滚动手感好。比如 less 里可以直接用左右方向键或者h/l横向滚动而 more 里的横向滚动逻辑就尴尬很多。大文件的另一个痛点就是搜索。less 搜索大文件时虽然第一次搜索需要扫描全文但它会记住匹配结果后续在全文范围内反复跳转都很快。而 more 的搜索我印象里每次搜索都不够智能部分实现搜索后无法回到搜索前的位置或者搜索过程容易卡顿。所以如果让我对一个几十 MB 的日志做深度排查我无脑选 less。偶尔会有极端情况文件接近几个 GB机器内存又很紧张。此时 less 的全功能加载策略可能会让内存有点吃紧但这不代表 more 就更适合。在这种机器上更好的方案是用tail、grep等工具先过滤再用 less 去查看过滤后的结果而不是拿 more 硬扛一个巨型文件。我见过有人在几 GB 的日志上直接more /var/log/xxx.log然后终端完全卡死最后只能 Ctrl-C 强制退出。这个教训可以记住当文本大到一定程度查看器本身的功能高级与否已经不重要重要的是你的工作流要合理比如先 grep 出关键行再查看。5. 管道与交互边界more 常用于“伪交互”less 却接管了整个终端在日常使用中很多命令的输出是很长的比如ps aux、systemctl status、dmesg。我们经常会顺手把它管道给 more 或 less例如dmesg | more。这两种方式看起来行为差不多但实际交互逻辑有区别。more 在管道模式下的处理策略相对简单它在读完当前屏内容后显示“--More--xx%”等待你的操作整个过程中它更像一个“分页器”一次从一个数据流里读取一块显示一块交互相对轻量。less 在管道模式下会先把整个输入数据读取到缓冲区然后再进入交互模式所以如果输入源特别大比如一个无限日志流less 一开始可能就会不断读数据直到把所有输入都读进缓冲区才进入可交互状态。这意味着如果你往 less 里管道一个无限输出的命令它可能永远卡在读取阶段而无法展示内容。这个点我用一个很具体的场景来解释我在写一些自动化运维脚本时如果要让机器“根据实际内容”来做判断more 和 less 都不合适应该直接用 grep/awk/sed 去解析文本而不是进入交互模式。但如果我在手动排查问题比如把journalctl -u myservice --since today | grep -i error | less这种经过 grep 过滤后的结果用 less 是完全没有问题的因为输出量已经被 grep 控制住了不会出现无限流。但是如果你直接journalctl -f -u myservice | less这个-f是持续输出的日志流less 可能会一直读下去不给你交互的界面因为数据源没有结束甚至到最后你看到的是零散内容或者一个失控的账单。more 在这个场景其实也好不到哪儿去因为它也拿不到一个明确的文件结尾。正确的做法是用journalctl -f时直接看终端输出或加--no-pager配合 grep而不是接 less 或 more。从这个点能看出 more 和 less 的边界more 适合简单的“看完即走”的管道输出分页不需要记住或回溯less 更适合需要深入分析、反复查阅的文件或者有限输出文本所以我在写博客或处理文档时会特意用 less 打开文本文件来定位特定段落因为它的交互能力和状态保持能力更符合“编辑器式”的阅读需求。这里特别需要一个提醒在脚本中使用 less 或 more 时它们的行为会受-F如果内容一屏能显示完就自动退出等参数的影响。less 带有-F参数在管道输出很短时直接退出不会出现“卡在 More 提示符”里的情况这对自动化处理是很友好的。而 more 在很多实现下遇到内容较短时也会直接退出但行为并不完全一致。写管道相关脚本时一定要测试好具体环境下的行为。6. 实操经验从入门到常用的进阶命令组合与避坑指南经过前面几轮分析结论其实已经很明显现代工作流中less 是更强大的选择。但这不代表 more 就毫无用处。在绝对精简的嵌入式环境、容器镜像里的精简用户态、或者恢复模式中有时候可能只有 more 而没有 less所以 more 的基本操作还是得会一点。我自己的命令行习惯是分三层来做文本浏览的小文本且不打算细看比如命令帮助不算长、文件很短直接 cat不接分页。中等长度文本或日志几十行到几百行直接 less因为随时可能搜关键字、上下翻。超大文件排查几百 MB 以上先用 grep、awk、sed 等工具过滤出我要的范围甚至把关键行重定向到临时文件然后再用 less 打开临时文件或者用 less 直接打开原文件加搜索模式。考虑到很多朋友可能刚开始接触这些命令我把最常用的几个 less 参数和操作整理成一个速查表大家可以打印出来贴到工位上命令/按键作用使用频率less file打开文件超高less -N file打开文件并显示行号高查日志时几乎必用less -S file超长行不折行横向滚动高查 JSON 日志神器less -i file忽略大小写搜索中/keyword正向搜索超高?keyword反向搜索中n/N下一个匹配 / 上一个匹配超高g/G回到文件开头 / 文件末尾高F大写类似tail -f的跟随模式高跟踪实时日志很舒服-S在 less 内部按切换是否折行高v用系统默认编辑器打开当前文件中编辑时用50%跳转到文件 50% 位置中让我单独说说less F这个模式。这是 less 里一个很常用的隐藏能力相当于“内置了 tail -f”。以前排查实时日志要么开两个终端一个 tail -f 跟踪一个 less 慢慢翻或者干脆关掉 tail 再打开 less。其实 less 里直接按大写F它就会进入“跟随模式”——文件有新内容就自动滚动和 tail -f 一样。想退出跟随模式返回静态模式按Ctrl-C就行了。这个功能在调试服务、观察日志时实在是太顺滑了我基本已经不用单独的 tail -f 来看日志都是 less F 一把梭。还有一个小技巧less 支持同时打开多个文件比如less file1 file2 file3然后用:n跳到下一个文件:p回到上一个文件。这在前后对比多个日志片段时很方便。比如我排查一个接口调用链往往要把入口日志文件、中间件日志、DB 日志一起打开这时less log1.log log2.log log3.log来回:n、:p非常省事。more 当然也支持多文件但切换的逻辑就没有 less 直观。踩坑方面我再补几个比较常见的。一个坑是环境变量 PAGER 的影响。很多命令工具比如git log、man、systemctl会读取PAGER或MANPAGER环境变量来决定用什么分页器。如果你在.bashrc里设置了export PAGERmore那么你用git log时可能就进入 more 的交互从上面分析知道往回翻大概率会遇到麻烦。所以我个人建议除非你明确知道自己在做什么否则把 PAGER 设置成 less 会好很多。我自己就吃过这个亏当年为了“轻量”把 PAGER 设为 more结果后来 git log 翻页时往回翻不了排查了半天才发现是这个变量作怪。另一个坑是管道输出给 less 时退出 code 是 0 的问题。在写某些脚本时如果用less作为分页器用户按 q 退出后管道的退出码会被吞掉变为 0这会导致脚本误判。more 也存在类似的情况。所以在自动化脚本里如果需要严格判断上游命令的成功与否不要依赖 less/more 的返回码应当通过set -o pipefail或者在管道前单独判断上游命令的退出码。比如ps aux | grep nginx || echo no process这种写法千万不要写成ps aux | grep nginx | less后去判断$?。还有一个容易忽视的坑是less 的-X参数。如果你的 TERM 环境变量比较特殊或者你在某些 CI 系统里调用 less遇到清屏问题时试试less -X它会禁止“退出时清屏”的动作也就是在 less 里按 q 退出后屏幕上依然保留当前内容不会黑屏或滚动回命令提示行。很多人说“less 退出后内容全没了”其实大多就是这个清屏行为导致的理解了-X就能控制它。7. 结合场景的选型建议和面试高频问题参考聊到这里可能有人会问那我是不是彻底不学 more 就行我的建议是基础了解 more主学 less。more 只需要掌握“空格下一页、回车下一行、q 退出”这三点就足够应急了。毕竟在某些极端精简环境里可能没有 less但一般都会带一个 more。用 more 应急时思路就是“只往后看别想着回头”错过了就错过了我们后续再用 grep/sed 去查。less 则要花点心思系统学一学因为它的能力远不止“翻页 搜索”。比如我上面提到的less -S、less F、多文件模式、标记跳转m标记、跳到标记处等每个能力在特定场景都能帮上大忙。特别是做日志分析的时候less 配合 grep、awk、sort、uniq 这些命令能构建一套非常高效的排查链路。关于当前非常火的面试题参考因为网络热词里出现了很多 Linux 面试相关词汇我也顺手梳理几个常见面试问法和参考回答方向方便大家自查Qmore 和 less 的主要区别是什么Aless 是 more 的增强版除了支持更多翻页方式还支持回卷、搜索高亮、跳转、跟随文件等高级功能。more 更轻量但交互能力弱。Q如何让 less 像 tail -f 一样跟随文件输出A用less F或者在 less 内按大写F。退出跟随模式按Ctrl-C。Qless 中如何忽略大小写搜索A命令行加-i参数或者搜索时使用/keyword/i。Q在管道中使用分页器时如何避免破坏上游命令的退出码A使用set -o pipefail或者在管道前单独判断上游命令的退出码。Q怎样在 less 中显示行号A启动参数加-N或者在 less 内部输入-N切换。Q如果你想快速查看一个超大日志文件中的特定关键字怎么做最高效A先 grep 过滤关键字再 less 查看结果或者直接 less 打开后/keyword搜索。因为 less 打开超大文件后搜索依然很快但不建议在超大文件里来回翻页做人工定位。这类面试问题我在给新人做培训时也经常问目的就是考察他是不是真在命令行里工作了足够的时间。如果一个人能脱口而出less -N和/keyword并且能解释为什么在高频日志分析场景选 less 而不是 more那至少说明他平时不是在“背命令”。最后再分享一个我自己操作中的体会区分一个命令是否优秀要看它在异常场景下的应变能力。more 在我需要向回翻时给我的只有沉默less 则给了我完整的回溯、搜索、标记、跟随能力。这种“被工具兜底”的安全感在工作效率提升上是实打实的。希望这篇文章能帮大家彻底理清 more 和 less 的差异也欢迎在评论区分享你用 less/more 时遇到过的好用技巧或奇葩坑咱们一起把这些命令玩得更溜。