ShareX 21.0.0 正式发布。对很多开发者、测试工程师和文档维护者来说，ShareX 不只是截图软件，而是一个“捕获、处理、上传、分享”的流水线工具。这次版本新增了 Background remover 和 Image Comparer，意味着它开始把一些原本需要外部工具完成的图像处理步骤收回到自己的工作流里。
这次更新真正影响的是工作流
ShareX 的核心能力一直很清楚：捕获或录制屏幕任意区域，然后把图片、文本或其他文件上传到超过 80 个支持的存储服务。它适合那些每天要截 Bug、录复现步骤、发 UI 差异、写内部文档的人。
21.0.0 的两个新增工具都踩在高频场景上：
- Background remover：适合处理头像、产品图、界面局部元素，把背景去掉后再贴进文档、工单或演示材料。
- Image Comparer：适合对比 UI 改动、截图回归、文档配图差异，尤其是前端、QA、技术写作场景。
这类功能的价值不在于“多一个按钮”，而在于减少上下文切换。以前你可能要截图后打开另一个图像工具，再导出，再上传；现在这些动作更可能留在 ShareX 里完成。
Background remover：不是设计软件，但能省掉很多碎活
背景移除通常出现在这些日常任务里：
- 把应用窗口里的某个控件抠出来，用在发布说明里。
- 从截图里提取一个图标、按钮或产品状态图。
- 给内部 Wiki 准备更干净的说明图片。
需要注意边界：ShareX 是截图与分享工具，不是 Photoshop。复杂毛发、透明玻璃、低对比边缘这类场景仍然可能需要专业工具修整。但对于技术文档里的“干净截图”和“局部素材”，内置 Background remover 已经足够改变流程。
可以这样实践：把 ShareX 的截图目录固定下来，再用脚本自动整理处理后的图片。下面这个 PowerShell 示例会把 ShareX 输出目录中的 PNG 文件按日期归档，适合搭配截图、抠图、对比图之后的素材管理。
运行前修改 $ShareXPath 为你的 ShareX 截图目录。
$ShareXPath = "$env:USERPROFILE\Documents\ShareX\Screenshots"
$ArchivePath = "$env:USERPROFILE\Documents\ShareX\Archive"
New-Item -ItemType Directory -Force -Path $ArchivePath | Out-Null
Get-ChildItem -Path $ShareXPath -Filter *.png -File | ForEach-Object {
$day = $_.LastWriteTime.ToString("yyyy-MM-dd")
$targetDir = Join-Path $ArchivePath $day
New-Item -ItemType Directory -Force -Path $targetDir | Out-Null
$targetFile = Join-Path $targetDir $_.Name
Move-Item -Path $_.FullName -Destination $targetFile -Force
Write-Host "Archived $($_.Name) -> $targetDir"
}
这段脚本没有依赖 ShareX 内部 API，只是围绕输出文件做自动化，所以风险低，也容易放进个人工具箱。
Image Comparer：给 UI 回归和文档审阅一个轻量入口
Image Comparer 的加入，对开发团队尤其实际。很多 UI 问题不是“完全坏了”，而是间距变了 2px、按钮颜色不一致、弹窗高度偏移。人工肉眼来回切图很累，也容易漏。
在 ShareX 里做图像对比，适合这些轻量场景：
- 发布前对比新版和旧版页面截图。
- 检查文档截图是否仍然匹配当前产品界面。
- 对比 Bug 修复前后的视觉状态。
- 快速判断一次样式改动是否影响了不该动的区域。
如果你已经有自动化测试，也可以把 ShareX 当作人工审阅入口，而不是替代 Playwright、Cypress 或 Percy 这类视觉回归方案。自动化适合稳定页面和 CI，ShareX 更适合临时判断、人工复核和沟通材料。
可以这样实践：用 Playwright 批量生成前后截图，再交给 ShareX 的 Image Comparer 做人工对比。下面是一个最小 Node.js 示例，会分别打开两个地址并保存截图。
运行前安装依赖，并把 URL 改成你的页面：
mkdir visual-check
cd visual-check
npm init -y
npm install playwright
npx playwright install chromium
创建 capture.js：
const { chromium } = require('playwright');
async function capture(url, output) {
const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
await page.goto(url, { waitUntil: 'networkidle' });
await page.screenshot({ path: output, fullPage: true });
await browser.close();
}
(async () => {
await capture('https://example.com', 'before.png');
await capture('https://example.com', 'after.png');
console.log('Saved before.png and after.png. Open them in ShareX Image Comparer.');
})();
执行：
node capture.js
这个例子不假设 ShareX 暴露命令行比较接口，只负责生成可比较素材。接下来用 ShareX 21.0.0 的 Image Comparer 打开 before.png 和 after.png，更适合人工判断视觉变化是否符合预期。
23 种语言翻译完成，团队环境会更顺手
这次更新还提到：除 Avalonia UI 窗口之外，所有 23 种语言都已 100% 翻译完成。对个人用户这可能只是界面更完整；对跨地区团队来说，它能降低工具推广成本。
截图工具经常被非工程岗位使用：产品、运营、客服、技术支持、文档团队都会参与截图和上传。如果工具菜单、提示、错误信息本地化更完整，内部培训和协作阻力会小很多。
Avalonia UI 窗口仍被单独排除，说明翻译完整度还不是绝对覆盖。升级后如果你的团队依赖某些新 UI 窗口，仍然需要实际检查语言显示是否符合预期。
升级建议：把 ShareX 当成一条小型媒体流水线
如果你只是偶尔截图，21.0.0 的新功能可能只是锦上添花。但如果你每天都在处理截图、录屏、上传和文档配图，可以认真升级并重新整理工作流。
建议按这个清单落地：
- 固定截图输出目录，避免素材散落在桌面和下载目录。
- 为 Bug、文档、发布说明分别建立命名规则。
- 用 Background remover 处理需要进入文档或演示的干净素材。
- 用 Image Comparer 辅助 UI 改动审阅，但不要把它当成完整视觉回归测试系统。
- 如果团队多人使用，升级后检查语言包、上传目标和快捷键配置。
ShareX 21.0.0 的重点不是变成大型图像编辑器，而是继续压缩“截图之后”的琐碎步骤。对高频截图用户来说，这比单纯多一个捕获模式更有价值。