滚动截图与长截图全解析：四种技术路线、参数调优与翻车修复

滚动截图这件事，说起来简单——不就是把一屏装不下的东西一次性存成一张图嘛。但真到用的时候，十个人里有八个会翻车：截网页截到一半白屏，截聊天记录接缝处重复半行字，截完发现顶部导航栏在每张图里都出现了一遍，最后拼出来像鬼畜视频的分镜表。我在过去几年里帮同事、帮朋友、也帮自己处理过几百次这类需求，从产品页存档、后台数据留证，到把一整个对话窗口导成一张图交给别人看，踩过的坑基本能编成一本小册子。这篇东西就是把这些经验摊开来讲：电脑滚动截图和截长图到底有哪几条技术路线，四种方法各自的适用边界在哪，参数怎么算，翻车了怎么修。不管你是完全没接触过的小白，还是已经用过几款工具但总觉得效果不稳的老手，下面的内容都能直接拿去用。

1. 先想明白：滚动截图的难点到底在哪

1.1 三条技术路线，决定了工具的上限

很多人以为滚动截图就是"按住截图键然后鼠标往下滚"，其实底层实现只有三条路，所有工具都是这三条路的变体，区别只在于包装得好不好看。

第一条是浏览器内核级整页渲染。浏览器本身是知道页面完整尺寸的，它可以把整个页面按完整高度重新渲染进一张画布，一次性吐出来。这条路出来的图最干净，没有接缝、没有重复元素，因为它压根不是"拼接"出来的，而是"一次画完"的。缺点是只有浏览器能用，而且受画布尺寸上限限制。

第二条是模拟输入 + 逐屏拼接。工具替你模拟滚轮或 PageDown，每滚一屏就截一张，最后在内存里把若干张图拼成一张。市面上绝大多数滚动截图工具走的是这条路。它的好处是通用——浏览器、聊天窗口、PDF 阅读器、代码编辑器，理论上什么窗口都能截。坏处也很明显：滚动过程中的中间态、动画、懒加载、固定定位元素，全都会变成接缝处的瑕疵。

第三条是程序化控制 + 分段截取。用脚本驱动浏览器或应用，精确控制滚动位置和截图时机，最后自己拼。这条路门槛最高，但可控性也最强，适合需要批量、定时、超高分辨率或者需要嵌入自动化流程的场景。

提示：判断一个滚动截图工具靠不靠谱，最简单的办法是拿一个带吸顶导航栏的页面去试。如果截出来的图里导航栏重复出现了好几次，说明它是第二条路且没做固定元素处理；如果只出现一次，说明它要么走的内核渲染，要么做了认真的固定层剥离。

1.2 为什么"一键长截图"经常翻车

翻车的根源，几乎都能归结到四个字：时间差。

逐屏拼接的原理是「滚一下、等一等、截一张」。这个"等一等"如果等得不够，截到的就是滚动动画进行到一半的画面，糊成一团；如果等得太多，页面上的轮播图、倒计时、视频封面已经换了一帧，前后两张图对不上。我见过最离谱的一次，是截一个带自动轮播的产品页，拼出来之后每一屏的头图都不一样，整张长图看起来像幻灯片。

第二个高频问题是懒加载。现在稍微像样一点的页面都做了图片懒加载，只有滚动到可视区域才开始加载。逐屏截图时如果滚太快，工具截到的就是占位灰块。有些工具会在截图后"顺便"往下滚，结果就是整张图下半部分全是灰色方块，用户还以为是自己网络不好。

第三个问题是固定定位元素重复。顶部导航、右下角客服悬浮球、底部 cookie 提示条，这些position: fixed的元素在每一屏都会出现一次。拼接工具如果不做特殊处理，就会把它们忠实复制 N 遍。

第四个问题是像素级对齐。滚动量如果不是整数像素，或者页面本身有transform: scale()、zoom之类的缩放，拼接时就会出现 1 到 2 像素的错位。肉眼看是"接缝处有一道淡淡的横线"，放大看是半行字被切成了两半。

1.3 四种方法的选型对照

在选择之前，先看清楚每种方法的能力边界，避免用锤子去拧螺丝。

实测下来，我的默认顺序是：能走浏览器内核就走内核，不能就走脚本，实在懒得写代码就用滚动截图工具，需要给别人发文档就用 PDF 路线。

2. 方法一：浏览器开发者工具整页截图，零成本最高清

2.1 一条命令搞定整页

这是我最常用的一招，因为它不需要装任何东西，任何 Chromium 内核的浏览器都自带。

操作路径如下：

1. 在目标页面按下F12，或者右键选择"检查"，打开开发者工具。
2. 保持开发者工具处于聚焦状态，按下Ctrl + Shift + P（macOS 上是Cmd + Shift + P），会弹出一个命令面板。
3. 在命令面板里输入screenshot，会看到几个候选命令，选Capture full size screenshot（中文界面显示为"截取完整尺寸的屏幕截图"）。
4. 浏览器会自动下载一张 PNG，就是整个页面的完整长图。

这里有个很多人会踩的小坑：必须让焦点在开发者工具面板上，如果你点回了网页正文再按Ctrl + Shift + P，触发的是别的东西。我第一次用的时候在这个细节上卡了五分钟，还以为是浏览器版本不支持。

命令面板里其实有三个相关命令，作用完全不同，别选错：

• Capture screenshot：只截当前视口，等于普通截图。
• Capture full size screenshot：截整个页面，这就是我们要的长图。
• Capture node screenshot：截选中的某个 DOM 节点。这个命令非常好用，比如你只想截页面中间那个表格，可以在元素面板里选中对应的<table>节点，再执行这条命令，出来的图就是干干净净的表格，没有导航栏、没有页脚、没有侧边广告。

Capture node screenshot这个功能我强烈建议记住，它解决的是"我只想要页面里某一块"的需求，比截全图再裁剪高效得多，而且不受页面总高度限制。

2.2 截图前必须做的三个前置动作

直接点命令截出来的图，十次里有六次是有瑕疵的。真正的老手在按命令之前，会先做三件事。

第一件，手动滚到底，把所有懒加载触发一遍。从头慢慢滚到页面底部，等图片全部加载完，再滚回顶部。这一步花不了三十秒，但能避免长图下半部分全是灰色占位块。如果页面有"加载更多"按钮，也一并点开。

第二件，把固定定位元素藏起来。在开发者工具的控制台里粘贴下面这行，回车执行：

document.querySelectorAll('*').forEach(el => { const s = getComputedStyle(el); if (s.position === 'fixed' || s.position === 'sticky') { el.style.visibility = 'hidden'; } });

这行脚本会把所有固定和粘性定位的元素隐藏掉。副作用是如果页面主体本身就是 sticky 布局，可能会误伤，这时候把sticky那个判断去掉，只处理fixed就够了。我更稳妥的做法是手动在元素面板里找到导航栏节点，直接按Delete键临时删掉，截完刷新页面即可恢复，零风险。

第三件，把页面宽度锁定到目标尺寸。浏览器默认按当前窗口宽度渲染，如果你想要一张 1440 宽的图，就得保证渲染宽度是 1440。做法是按Ctrl + Shift + M打开设备模拟工具栏，在顶部的尺寸输入框里填自定义宽高。这一步会顺带解决另一个问题：设备模拟模式下页面通常会隐藏滚动条，长图边缘不会出现那条灰黑色的滚动条残影。

2.3 分辨率怎么算，以及为什么超长页面会截断

这一节讲点硬核的，理解了之后你就知道什么时候该换方法。

内核整页截图的输出尺寸，等于CSS 宽度 × 设备像素比乘以CSS 高度 × 设备像素比。假设页面 CSS 宽度 1440、完整高度 12000，设备像素比是 2（高分屏常见值），那么输出图片就是2880 × 24000 像素，接近 6900 万像素。

这个数字意味着什么？RGBA 每个像素占 4 字节，6900 万像素光像素数据就要276MB，加上编码缓冲、压缩中间态，实际内存占用轻松翻倍到 600MB 以上。如果页面高度再翻一倍，浏览器进程很可能直接崩掉，或者给你一张下半部分全黑、全白的残图。

所以有一条经验阈值：单张长图的总像素数控制在 3000 万以内最稳妥，超过 6000 万就要做好失败准备。换算成具体尺寸大概是：

看最后两行就明白了：在 2 倍屏上，页面高度超过 5000 CSS 像素就进入危险区了。而现实中的商品详情页、条款页面动辄一两万像素高。

遇到这种情况，我的处理办法是降设备像素比。在设备模拟工具栏里把 DPR 从 2 改成 1，输出尺寸直接减半，像素量降到四分之一，绝大多数超长页面都能一次成功。代价是清晰度下降，但如果你最终用途是发在聊天窗口里给人看，1 倍图完全够用，甚至更合适——2 倍图动辄 20MB，发都发不出去。

如果连 1 倍图都截不下，那就老老实实换方法三或方法四，分段截取再拼接。

3. 方法二：打印成 PDF 再转换，超长页面的稳妥退路

3.1 打印预览里的几个关键设置

这条路子经常被忽略，但它在处理"超长文档型页面"时特别稳，因为它压根不涉及内存里的大画布，浏览器是分页渲染的，天然不会崩。

操作步骤：

1. 在页面上按Ctrl + P打开打印对话框。
2. 目标打印机选择"另存为 PDF"。
3. 展开"更多设置"，把纸张尺寸改成 A3 或自定义，边距选"无"，缩放选"默认"或"自定义 100%"。
4. 如果页面上有导航栏、侧边栏、评论区这些不想保留的部分，勾选"背景图形"关掉之后配合页面自身的"打印样式"往往能自动隐藏，很多站点都做了打印适配。
5. 点击保存，得到一个 PDF 文件。

这套流程的优势在于：分页是明确的。你拿到的是一份结构清晰的文档，不会出现某一页被拦腰截断的情况（虽然偶尔会有，但那是页面自身打印样式的问题，可以在打印预览里实时看到并调整缩放比例规避）。

我通常用它来处理两类内容：一是几百页的产品手册、条款、教程，二是需要长期归档、发给别人看的资料。PDF 本身就是归档格式，比一张几万像素的 PNG 更适合传递。

3.2 PDF 转长图的两种做法

拿到 PDF 之后要变成一张长图，有两个方向。

方向一：转成图片再纵向拼接。用任意 PDF 阅读器的导出功能，把每一页导出成 PNG，然后用图片处理工具纵向拼起来。命令行下用图像处理库几行代码就能搞定：

from PIL import Image import glob files = sorted(glob.glob("page-*.png")) imgs = [Image.open(f) for f in files] width = max(i.width for i in imgs) total_h = sum(i.height for i in imgs) canvas = Image.new("RGB", (width, total_h), "white") y = 0 for i in imgs: canvas.paste(i, (0, y)) y += i.height canvas.save("merged.png")

这段代码的逻辑很直白：先算出所有页面的最大宽度和总高度，建一块白色画布，然后逐页贴上去。注意sorted()那一步不能省，文件系统返回的顺序不保证是 1、2、3、10 这样的自然序，很容易拼出page-1, page-10, page-2这种乱序结果。我踩过这个坑，拼出来一份 60 页的文档，页码全乱，重新跑了一遍才发现问题。

方向二：转成一份超长图片 PDF 再统一处理。有些 PDF 工具支持"多页合并为单页"布局，在打印设置里选择"海报"或"平铺"模式，把 N 页铺成一张。这个方式输出质量一般，但胜在一步到位。

注意：PDF 转图默认分辨率通常是 96 或 150 DPI，出来的图放到大屏上看会有点糊。如果最终用途需要清晰，导出时把 DPI 提到 200 到 300，代价是文件体积会涨到原来的三到四倍，做好心理准备。

4. 方法三：滚动截图工具逐屏拼接，聊天记录的主战场

4.1 拼接原理与三个必须调好的参数

前面说过，这类工具的工作方式是「滚动—等待—截图—拼接」。要让它稳定工作，本质上是帮它把"等待"这件事控制好。有三个参数直接决定成败。

第一个是滚动步长。步长太大会漏内容，步长太小会产生大量重叠、拼接耗时长。经验值是视口高度的 85% 到 90%，留出 10% 到 15% 的重叠区给拼接算法做特征匹配。有些工具允许手动设置重叠像素，我一般设 80 到 120 像素，这个区间既能保证匹配准确，又不会浪费太多。

第二个是滚动后的等待时间。默认值通常只有 100 到 300 毫秒，对本地页面够用，但对需要联网加载内容的页面完全不够。我统一调到800 毫秒到 1.2 秒。慢是慢了点，但一次成功的慢，胜过三次失败的快。

第三个是平滑滚动开关。这条最容易被忽略。系统或浏览器的"平滑滚动"功能会让滚动过程变成一个缓动动画，工具在动画中途截图，拿到的就是半个屏幕糊、半个屏幕清楚的残图。用这类工具之前，务必去系统设置里把平滑滚动关掉，或者在浏览器里通过启动参数禁用。

4.2 通用操作流程与现场记录

以最常见的"框选区域滚动截取"为例，完整流程是这样的：

1. 把目标窗口调整到合适大小。这一步很关键——窗口越接近正方形，单屏能容纳的内容越多，需要的拼接次数越少，出错概率越低。我的习惯是把窗口拉到占屏幕高度的 80% 左右，宽度适中。
2. 关闭页面上一切会动的东西：自动播放的视频、轮播图、闪烁的提示、光标闪烁的输入框。输入框的处理方式是点一下页面空白处让它失焦，或者直接按Esc。
3. 把内容滚动到起始位置，通常是页面或对话的最顶部。
4. 启动工具，框选要截取的区域。框选时要避开滚动条，否则每一屏的右边缘都会带一条滚动条，拼出来就是一条断断续续的灰线。
5. 点击开始，然后不要碰鼠标键盘。这时候任何输入操作都可能干扰滚动模拟。
6. 等工具自动滚到底部，它会弹出预览。在预览里重点看三个地方：接缝处有没有重复行、固定元素有没有重复出现、底部有没有截断。
7. 保存。优先存 PNG，需要控制体积再转 JPG。

实测下来，一个高度约 8000 像素的页面，按 85% 步长大概需要 11 到 12 屏，整个流程耗时 15 秒左右。这个速度是可以接受的。

4.3 聊天记录长图专项：把一整个对话塞进一张图

这是被问得最多的场景。截聊天记录和截网页完全是两码事，因为聊天窗口有几个独特性质：消息是往上翻的、内容会折叠、有大量头像和气泡、时间戳会重复。

先解决"往上翻"的方向问题。很多滚动截图工具默认是"从上往下滚"，而聊天记录需要的是"从下往上"。如果你的工具支持反向滚动，直接开；不支持的，先把对话滚到最早的那条消息，再从那里开始往下截，效果一样。

然后是展开折叠内容。聊天窗口里通常有"查看更多消息"、"展开全文"、图片的"查看原图"这类入口，如果不点开，长图里就是一堆"[图片]"占位。截之前花两分钟把这些都点开，值得。

接着处理重复元素。聊天窗口顶部有标题栏和"返回"按钮，底部有输入框，这两个都是固定的，会重复出现在每一屏。处理方式是在截图前把窗口拉高，让固定栏占比尽可能小，或者在后期用裁剪把每一屏的顶栏和底栏切掉再拼。我一般选后者，虽然多一道工序，但结果干净。

最后一个技巧：提高消息密度。把聊天窗口的字体调小一档、把窗口拉宽、把侧边栏收起来，单屏能容纳的消息条数能从 8 条提到 15 条以上，需要的拼接屏数直接减半，出错概率也跟着降。

提示：如果对话特别长，比如几万字，别硬截一张图。分成三段截，每段之间留个明显的分隔，最后拼成一张纵向长图或者干脆发三张。一张 30000 像素高、文件 40MB 的图，接收方打开都费劲，沟通效率反而更低。

5. 方法四：脚本自动化，批量与超高分辨率的解法

5.1 完整可运行的分段截取脚本

当你需要截几十个页面、或者需要一张比浏览器上限还长的图、或者要把截图嵌进自动化流程，就得自己写。下面这段是能直接跑的，用的是无头浏览器加图像处理库的组合。

import io from playwright.sync_api import sync_playwright from PIL import Image TARGET_URL = "https://example.com" VIEW_W, VIEW_H = 1440, 900 DPR = 2 OVERLAP_CSS = 100 # CSS 像素单位的重叠量 MAX_SEGMENTS = 40 # 保险丝，防止死循环 def capture_full_page(url): with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page( viewport={"width": VIEW_W, "height": VIEW_H}, device_scale_factor=DPR ) page.goto(url, wait_until="networkidle") # 1. 隐藏滚动条和固定定位元素 page.add_style_tag(content=""" ::-webkit-scrollbar { display: none !important; } *[style*="fixed"] { visibility: hidden !important; } """) # 2. 预热：滚到底再回顶，触发所有懒加载 page.evaluate(""" async () => { const step = window.innerHeight * 0.8; for (let y = 0; y < document.body.scrollHeight; y += step) { window.scrollTo(0, y); await new Promise(r => setTimeout(r, 250)); } window.scrollTo(0, 0); await new Promise(r => setTimeout(r, 500)); } """) total_h = page.evaluate("document.documentElement.scrollHeight") step = VIEW_H - OVERLAP_CSS tiles, offsets = [], [] y = 0 count = 0 while y < total_h and count < MAX_SEGMENTS: page.evaluate(f"window.scrollTo(0, {y})") page.wait_for_timeout(400) buf = page.screenshot(clip={ "x": 0, "y": 0, "width": VIEW_W, "height": VIEW_H }) tiles.append(Image.open(io.BytesIO(buf))) offsets.append(y) y += step count += 1 browser.close() # 3. 拼接：除最后一张外，每张只保留顶部 step 高度的内容 step_px = step * DPR total_px = total_h * DPR canvas = Image.new("RGB", (VIEW_W * DPR, total_px), "white") for idx, img in enumerate(tiles): keep = step_px if idx < len(tiles) - 1 else img.height canvas.paste(img.crop((0, 0, img.width, min(keep, img.height))), (0, idx * step_px)) canvas = canvas.crop((0, 0, VIEW_W * DPR, total_px)) canvas.save("full_page.png") print(f"完成，共 {len(tiles)} 段，输出 {canvas.size}") if __name__ == "__main__": capture_full_page(TARGET_URL)

这段代码有几个设计点值得展开讲。

为什么要裁剪而不是用特征匹配拼接？因为滚动位置是我们自己精确控制的，window.scrollTo(0, y)的 y 是确定值，第二张图的第一行像素，物理上就等于第一张图的第step_px行像素。既然位置已知，直接按偏移量裁掉重叠区就行，无需做图像识别。这比通用拼接算法快一个数量级，也几乎没有错位风险。前提是页面没有做滚动劫持、没有惯性滚动、高度在截取过程中不会变化。

为什么重叠量设 100 CSS 像素？这是给滚动舍入误差留的余量。浏览器的scrollTo在某些缩放比例下会有 1 到 2 像素的非整数偏移，浏览器会把最终滚动位置取整，这个误差会累积。留 100 像素的重叠，即使误差上下游走几像素，也不会造成内容丢失。留得再多就浪费了，拼接时间会明显增长。

MAX_SEGMENTS这个保险丝为什么必要？因为有些页面会无限加载，scrollHeight每滚一次就增加一点，while 循环永远结束不了。加上这个上限，最坏情况是截取不完整，而不是脚本跑到天荒地老。

设备像素比为什么设 2？如果你要的图是给屏幕看的，1 倍就够，2 倍会让内存占用翻四倍、文件体积翻四倍。我通常只在需要打印、或者需要放大看细节的时候才上 2 倍。

5.2 参数选择背后的内存账

上一节脚本里所有参数的取舍，本质都在算一笔内存账。

按VIEW_W=1440, VIEW_H=900, DPR=2计算，单张截图的实际像素是 2880 × 1800，约 518 万像素。如果页面总高度 20000 CSS 像素，DPR=2 后是 40000 像素，最终画布是 2880 × 40000，1.15 亿像素。RGBA 状态下光像素内存就要460MB，paste过程中还可能需要副本，峰值接近 900MB。这在普通办公电脑上是能跑但很吃紧的。

如果 DPR 降到 1，同样的页面，最终画布 1440 × 20000，2880 万像素，占用降到约 115MB，一下就从"冒险"变成了"轻松"。

所以我在脚本里通常这么配：

还有一个容易被忽略的点：Image.new("RGB", ...)里的模式选择。用RGB而不是RGBA，能直接省掉 25% 的内存，因为网页截图基本不需要透明度，强行保留 alpha 通道是浪费。这个改动一行代码，效果立竿见影。

6. 后处理：把"能看"变成"能交付"

6.1 裁剪、对齐与接缝修复

不管用哪种方法拿到的原始长图，交付前都值得花两分钟做一道后处理。

裁剪掉边缘残留。方法三拼出来的图，左右边缘常常带滚动条残影或者 1 到 2 像素的白边。统一裁掉左右各 3 到 5 像素，观感立刻干净。顶部和底部如果有多余的固定栏，一并裁掉。

修接缝。如果接缝处出现了重复的一行字，说明拼接时重叠区算多了；如果出现了一行字被切成上下两半，说明重叠区算少了。前者用裁剪补，后者只能重截。我的经验是，只要重叠量给到 80 像素以上，被切断的概率极低。

处理固定层重复。如果图里导航栏出现了五次，最省事的办法是按固定的间隔把它们切掉——因为每一屏的高度是已知的，重复元素出现的位置也是规律的。写个小脚本按固定 y 坐标裁掉那几行，比重新截图快得多。

统一背景色。有些页面主体是深色、页脚是浅色，拼接后中间会有明显的色带。这不是技术问题，是页面本身设计如此，接受它就好，不要试图用填充色去"修"，越修越假。

6.2 压缩、分卷与安全发送

一张 2880 × 40000 的 PNG，体积轻松到 30MB 以上。这个体积在很多聊天窗口里会被压缩得惨不忍睹，甚至直接发送失败。所以压缩这一步不能省。

我的处理顺序是：先缩尺寸，再调质量，最后换格式。

尺寸上，把宽度压到 1280 或 1440，高度按比例缩。这一步的收益最大，宽度腰斩，像素量降到四分之一。质量上，如果存 JPG，把质量设在 80 到 85，肉眼几乎看不出差别，体积能降到 PNG 的三分之一。格式上，如果接收方支持，WebP 在同等观感下比 JPG 再小 25% 左右。

如果内容实在太长，压缩后还是超过 10MB，那就分卷。按内容逻辑切分，比如按章节、按对话轮次、按页眉分隔，切成 3 到 5 张，命名成part1、part2这样。分卷比一张巨图好用得多，接收方可以按需查看，也不用等半天加载。

注意：如果长图里含敏感信息，比如后台数据、订单详情、对话里的手机号，交付前记得打码。打码不要用半透明模糊，模糊处理在部分算法下是可以被一定程度还原的，用纯色块覆盖更稳妥。

7. 常见问题与排查速查表

7.1 六类高频故障与对应解法

下面这张表是我这些年遇到过的问题清单，按出现频率排序，遇到问题直接查。

除了这些技术性故障，还有两类"非技术"问题值得单独说。

一是页面高度在截取过程中变化。有些页面加载完广告位之后高度会跳变，你按初始高度算好的分段数就不够了，最后一段会缺失。解决办法是在脚本里先等networkidle，再额外等 1 秒，然后重新读一次scrollHeight，用最新值计算。

二是滚动被页面劫持。少数页面会监听滚动事件做视差效果或者滚动吸附（scroll snapping），window.scrollTo之后页面会被"吸"到某个位置，导致实际滚动量和预期不符。遇到这种页面，我一般直接放弃脚本方案，改用分段截图加人工核对，或者干脆用方法二的 PDF 路线绕开。

7.2 几条只有踩过坑才知道的经验

第一条，先用小页面验证工具链，再上大页面。我刚开始用某款滚动截图工具的时候，直接拿一个两万像素高的商品页去试，失败了三次，一直在怀疑工具本身有问题。后来换了个普通文章页测试，一次成功，才确认是页面高度超限。先用简单的验证，能省掉大量无谓的自我怀疑。

第二条，截图前把显示器缩放调到 100%。Windows 上常见的 125%、150% 缩放，会让浏览器的 CSS 像素和物理像素之间多一层换算，某些截图工具在这个环境下算出来的滚动量是错的，拼出来会有规律性的错位。调到 100% 截完再调回来，比事后修补容易得多。

第三条，保存原始分段图。如果你用的是分段截取方案，那些单屏截图别急着删。拼接结果有问题时，你只需要改拼接参数重跑一遍，不用重新截取，能省下大量时间。我习惯建一个raw/目录专门放这些中间产物，确认成品没问题再清理。

第四条，给长图加一条定位辅助线。如果这张图是要发出去让别人看的，在顶部和底部各加一条细色的分隔线，或者加一个简单的标题条，标明来源和时间。看起来是小细节，但接收方能一眼判断这张图从哪开始、到哪结束，少问好几个问题。我吃过没加标题条的亏，一张三万像素的长图发过去，对方第一句就是"这是从哪截的"。

第五条，别迷信"一键"。所有号称一键搞定的滚动截图工具，在复杂页面上都会翻车。真正稳定的做法是理解原理之后手动控制关键参数——滚动量、等待时间、重叠区。这三个数字调对了，任何工具都能出好结果；调不对，换十款工具也一样。

最后分享一个我最近用得很多的思路：如果你只是想把一屏装不下的内容给别人看，先想想是不是真的需要一张图。很多时候，一段文字说明加上两三个关键位置的截图，比一张几十屏的长图表达效率高得多。长图这东西，适合归档、适合留证、适合展示完整的视觉结构，但不适合代替沟通。我早期特别迷恋把所有东西都截成一张长图，后来发现对方根本没耐心往下翻，反而是分段的几张关键截图更容易被认真看完。工具是手段，把事情说清楚才是目的。