活动页上线后，运营同事发来截图，说主图看起来发虚，怀疑网站出了故障。打开页面查看，图片确实不够锐利，但服务器状态正常，页面也能正常加载。这类反馈在网站维护中很常见，问题往往不在网站本身，而在于WEBP格式在高压缩与清晰度之间的取舍被误判成了技术故障。WEBP的优势是体积小，代价是压缩参数设置不当会损失细节，排查时需要按层次推进，避免一上来就改代码。
第一层先核对源文件本身。拿到图片后先看原始像素尺寸，如果原图只有八百像素宽，却要铺满一千二百像素的容器，放大后必然发虚。再看压缩质量参数，WEBP在质量值较低时对纹理和渐变区域的处理比较明显，文字边缘和细线条容易糊。还要确认文件是否经过多次转码，比如从JPG转WEBP后又转了一次，每次转码都会叠加损失。查看文件信息的通用方法是右键查看属性或使用系统自带的预览工具读取尺寸，有条件时用图像处理软件打开看实际像素与文件体积是否匹配。
第二层核对网页端呈现。图片容器尺寸与图片原始尺寸是否匹配是首要判断点，容器远大于原图就会拉伸。接着看CSS缩放方式，直接设置宽高百分比而忽略object-fit，可能让图片变形或模糊。响应式场景下还要检查多倍图是否匹配，给高分屏提供了单倍图，显示效果就会偏软。常见错误包括给图片写死固定高度导致比例失调，以及在小屏断点仍加载大图再压缩显示，既浪费流量又影响观感。
第三层核对传输与缓存。CDN或浏览器缓存可能返回旧版本图片，明明替换了清晰版，用户看到的还是旧文件。验证思路是清除缓存后强制刷新对比，或在链接后加临时参数观察变化。还要留意格式协商是否降级，部分环境不支持WEBP时会回退到其他格式，回退图如果没有同步更新，清晰度就会不一致。对比验证时固定同一设备同一网络，逐项排除变量。
给出一份六项检查清单：一查原图像素尺寸是否满足展示需求，二查压缩质量参数是否过低，三查是否经历多次转码，四查容器尺寸与缩放方式是否合理，五查响应式多倍图是否匹配，六查缓存与格式回退是否返回旧版。维护记录中应留存原图尺寸、压缩参数、替换时间、缓存刷新记录和用户反馈截图，便于后续复盘定位。
it数运在网站维护中强调把技术问题分层说明白，先分清是源文件、呈现还是传输环节，再动手处理。按这个顺序排查，多数图片发虚的反馈都能在半小时内找到原因，也能避免把正常的压缩取舍误当成网站故障。
