内容站做爬虫时，图片处理不能只靠“正文里有什么就显示什么”。稳定的流程应该把下载、压缩、裁剪、尺寸记录、上传和默认图都纳入任务系统，否则列表页、置顶页和详情页很容易出现尺寸混乱。
标准流程
一条完整的图片处理链路可以拆成：
- 爬取内容。
- 从正文中解析图片 URL。
- 下载图片。
- 识别原图尺寸和格式。
- 压缩图片。
- 按目标场景裁剪。
- 上传到对象存储或图片服务。
- 保存图片记录。
- 回写文章图片字段或保留映射关系。
其中最容易被忽略的是“保存记录”。如果不记录原图、处理后图片、尺寸、文章 ID 和类型，后续迁移存储或全局替换会很麻烦。
图片类型要按页面场景设计
内容站通常不只有一种图。常见类型包括：
- 列表缩略图。
- 列表大图。
- 置顶图。
- 小组件图。
- 默认图。
- 正文代理图。
不同类型尺寸不同，不能每次显示时临时裁剪。更稳的方式是在图片处理任务里生成多个派生版本，并记录类型。
数据库字段怎么放
有两种常见方式：
- 独立图片表：文章 ID、原图 URL、处理后 URL、宽、高、类型、状态、错误信息。
- 文章表 JSON 字段：把多个图片版本存在一个 JSON 里。
独立表更适合后续扩展和排查，JSON 字段适合简单系统。只要图片处理会重试、迁移、统计和复扫，就更建议使用独立表。
定时任务要小批量可恢复
图片处理任务可以这样设计：
- 每次查询少量文章，例如 10 条。
- 只处理最近几天或明确状态的数据。
- 处理状态落库，失败保留错误信息。
- 需要重试时按状态继续跑。
- Redis 可以保存短期待处理集合，但最终状态仍应以数据库为准。
如果图片非常多，要避免一次性扫描全库。
裁剪要以中心点和比例为核心
裁剪图片时，先判断原图宽高是否满足目标尺寸，再按中心点计算裁剪区域：
- 中心点 X = 原始宽度 / 2。
- 中心点 Y = 原始高度 / 2。
- 左上角 X = 中心点 X – 目标宽度 / 2。
- 左上角 Y = 中心点 Y – 目标高度 / 2。
这样能减少主体被裁掉的概率。但如果图片内容差异很大，后续可以引入人脸检测、显著性区域或人工兜底。
缩放方式要避免失真
“按宽高强行缩放”和“按比例缩放”不同：
- 强行缩放到目标宽高，会破坏原始比例，图片可能变形。
- 按比例缩放能保留视觉自然度，但可能需要裁剪或留白。
列表图通常更适合“等比缩放 + 居中裁剪”，详情图更适合保留原比例。
Java 图片工具怎么选
常见选择：
BufferedImage：JDK 自带，控制力强，但代码偏底层。- Thumbnailator：封装好，适合缩放、压缩和生成缩略图。
- Hutool
ImgUtil：适合快速处理常规图片任务。 - imgscalr：专注缩放质量。
如果项目已经使用 Hutool，可以先用 ImgUtil 做基础处理；如果图片质量要求更高，再引入专门库。
默认图要提前准备
不是每篇文章都有合适图片。默认图可以按分类提前生成一批，并在图片表里标记为默认图。这样列表页不会因为缺图而崩，也不会每次都随机找一张不相关的图片。
实用结论
爬虫图片处理的核心是“流程化”和“可追踪”。下载、压缩、裁剪、上传、尺寸、文章映射和默认图都要有状态记录。这样后续换存储、改尺寸、补图和排查失败任务时，才不会变成全站手工修图。
正文完
