Web on Snow

常见图片格式全解析：JPG、PNG、GIF、WebP、AVIF、SVG 有什么区别？

Thu, 17 Sep 2026 13:55:26 +0800

常见图片格式全解析：JPG、PNG、GIF、WebP、AVIF、SVG 有什么区别？

平时保存图片时，我们经常会看到 .jpg、.png、.gif、.webp、.svg 这些后缀。它们看起来都能“显示一张图”，但背后的设计目标完全不同：有的适合照片，有的适合截图，有的适合图标，有的适合动画，有的适合印刷或后期处理。

理解图片格式的核心，不是背后缀名，而是看它在几个问题上的取舍：是否压缩、是否有损、是否支持透明、是否支持动画、适合照片还是图形、文件体积和兼容性如何。

一、先搞懂几个关键概念

在具体看格式之前，先把几个常见术语捋清楚。

概念	含义	对选格式的影响
位图	用一个个像素记录图像	照片、截图通常是位图，放大后会模糊
矢量图	用路径、形状、颜色描述图像	图标、Logo、示意图适合矢量，放大不失真
有损压缩	压缩时丢掉一部分细节	体积小，但反复保存会降低画质
无损压缩	压缩后能还原原始像素	适合截图、文字、设计稿，但体积可能更大
透明通道	支持背景透明或半透明	做图标、贴纸、UI 素材时很重要
动画	支持多帧连续播放	表情包、短动图会用到

一句话概括：照片优先考虑有损高压缩，图标和截图优先考虑无损与透明，Logo 和插画优先考虑矢量。

二、常见图片格式逐个看

1. JPG / JPEG：最常见的照片格式

JPG 和 JPEG 本质上是同一种格式，只是扩展名写法不同。它最大的特点是有损压缩，非常适合存储自然照片，比如风景、人像、商品图。

优点：

压缩率高，文件体积通常较小
兼容性极好，几乎所有设备和软件都能打开
很适合色彩连续、细节丰富的照片

缺点：

不支持透明背景
不适合文字、线条、截图，容易出现模糊和噪点
反复编辑并保存会逐渐损失画质

适合场景：博客封面照片、相机导出的普通照片、商品照片、社交平台图片。

不适合场景：Logo、图标、带透明背景的素材、文字截图、需要长期反复编辑的源文件。

2. PNG：清晰、无损、支持透明

PNG 是一种无损压缩位图格式，常用于截图、UI 素材、透明图标和需要保留清晰边缘的图片。

优点：

无损压缩，文字和线条边缘清晰
支持 Alpha 透明通道，可以做半透明效果
适合截图、按钮、图标、设计稿预览

缺点：

对照片的压缩效率不如 JPG、WebP、AVIF
大尺寸照片保存成 PNG 时体积可能非常大

适合场景：软件截图、网页截图、二维码、透明背景图片、UI 元素、需要保持像素级清晰的图。

不适合场景：大量高清摄影图、博客中体积敏感的大图。

3. GIF：老牌动图格式

GIF 最出名的是“动图”。它历史很久，兼容性强，但技术上比较老：颜色最多只有 256 色，所以复杂画面容易失真。

优点：

支持简单动画
兼容性非常好
适合小尺寸、短循环、颜色简单的动图

缺点：

颜色数量有限，不适合高质量照片
文件体积经常比看起来更大
透明效果很弱，只支持简单透明，不支持平滑半透明

适合场景：简单表情包、小图标动画、低色彩短循环动画。

不适合场景：长视频片段、复杂色彩动画、高清动效。很多时候，用 WebP、APNG 或直接用视频格式会更合适。

4. WebP：Web 场景的实用型选手

WebP 是面向网页优化的图片格式，既支持有损压缩，也支持无损压缩，还支持透明和动画。它经常可以在保持相近视觉质量的情况下，比 JPG、PNG、GIF 更小。

优点：

同时支持有损、无损、透明、动画
通常比 JPG/PNG/GIF 更省体积
很适合网站图片优化

缺点：

在一些老旧软件或旧系统中兼容性不如 JPG/PNG
作为长期归档格式不如 JPG、PNG、TIFF 普遍

适合场景：网页配图、博客图片、缩略图、透明 Web 素材、动图替代。

不适合场景：需要给所有传统软件直接打开的图片归档、印刷交付源文件。

5. AVIF：更高压缩率的新一代格式

AVIF 基于 AV1 编码技术，压缩效率很高。它通常能在相同画质下比 JPG 和 WebP 更小，尤其适合需要极致压缩的 Web 图片。

优点：

压缩率很高，适合节省带宽
支持透明、HDR、高色深等现代特性
对复杂照片和渐变画面表现很好

缺点：

编码速度通常比 JPG/WebP 慢
老旧浏览器、图片软件、内容系统的支持可能不完整
调试和批量处理工具生态没有 JPG/PNG 那么成熟

适合场景：追求加载速度的网页图片、移动端流量敏感页面、图片数量很多的网站。

不适合场景：要求最大兼容性的图片分发、编辑链路复杂的素材流转。

6. SVG：图标、Logo、示意图的首选

SVG 不是位图，而是矢量图格式。它本质上是 XML 文本，用路径、形状、颜色来描述图像，所以可以无限放大而不失真。

优点：

放大不失真，适合高清屏
文件体积通常很小，尤其适合简单图形
可以用 CSS 控制颜色、大小和动画
适合 Logo、图标、流程图、架构图

缺点：

不适合复杂照片
复杂 SVG 也可能变得很大、渲染变慢
来自不可信来源的 SVG 需要谨慎处理，避免脚本或外链风险

适合场景：网站 Logo、图标、技术示意图、流程图、架构图、可缩放插画。

不适合场景：照片、复杂纹理图、真实光影图像。

7. HEIF / HEIC：手机照片里常见的高效格式

HEIF 是容器格式，HEIC 是 Apple 设备上常见的 HEIF 文件扩展名。很多手机会默认用它保存照片，因为它比 JPG 更省空间，还能保存更多信息。

优点：

体积通常比 JPG 更小
支持更高色深、多图、景深、Live Photo 等扩展信息
很适合手机本地照片存储

缺点：

Web 直接使用不如 JPG/WebP 普遍
Windows、旧设备、部分网页系统打开时可能需要转换
分享给他人时经常要转成 JPG

适合场景：手机照片存储、相册备份、Apple 生态内流转。

不适合场景：网页直接展示、跨平台无障碍分享。

8. TIFF：印刷、扫描和归档常用

TIFF 常见于扫描仪、出版、印刷、医学影像和专业图像归档。它可以支持无损压缩、高色深、多页图像和丰富元数据。

优点：

画质保真度高
支持高色深和专业色彩管理
适合扫描、印刷、档案保存

缺点：

文件通常很大
不适合作为网页图片
普通用户日常分享不方便

适合场景：印刷交付、扫描归档、专业修图中间文件、文档影像。

不适合场景：网页加载、社交分享、普通博客配图。

9. BMP：简单但体积大的老格式

BMP 是 Windows 生态里很早期的位图格式，结构简单，但通常压缩能力弱，文件体积大。

优点：

格式简单
在 Windows 环境中兼容性好

缺点：

体积大
不适合网络传输
现代实际使用场景越来越少

适合场景：某些老软件、测试图像处理流程、特殊 Windows 程序兼容。

不适合场景：网页、博客、日常图片分享。

10. RAW：相机保留的“数字底片”

RAW 不是单一格式，而是一类相机原始数据格式，比如 .cr2、.nef、.arw、.dng 等。它保存的是传感器捕获的原始信息，适合后期处理。

优点：

保留最多原始信息
后期调整曝光、白平衡、色彩空间更灵活
适合专业摄影工作流

缺点：

文件很大
不能直接作为网页图片使用
需要 Lightroom、Capture One、Photoshop 等软件处理

适合场景：摄影后期、商业修图、需要最大调整空间的原始素材。

不适合场景：直接上传网页、聊天分享、最终交付图。

三、一张表看懂区别

格式	压缩方式	透明	动画	主要优势	主要短板	最适合
JPG/JPEG	有损	否	否	照片体积小，兼容性强	不支持透明，文字边缘易糊	照片、封面图
PNG	无损	是	通常否	清晰、支持透明	大照片体积大	截图、透明素材
GIF	无损但限色	简单透明	是	兼容性强，能做动图	颜色少，体积不经济	简单短动图
WebP	有损/无损	是	是	Web 体积优化好	老旧环境兼容性一般	网站图片、动图替代
AVIF	有损/无损	是	可支持	压缩率很高，画质好	编码慢，生态仍需注意	高性能网页图片
SVG	矢量	是	可支持	放大不失真，可被 CSS 控制	不适合照片	Logo、图标、示意图
HEIC	有损/无损	可支持	可支持	手机存储效率高	跨平台分享常需转换	手机照片
TIFF	可无损	可支持	多页为主	专业、高保真、可归档	体积大，不适合 Web	印刷、扫描、归档
BMP	通常无压缩	可支持	否	简单、老系统兼容	体积大，过时	特殊兼容场景
RAW	原始数据	不作为成品图	否	后期空间最大	需专业软件处理	摄影源文件

四、几个最容易混淆的对比

JPG vs PNG

如果是照片，用 JPG；如果是截图、文字、线条、透明背景，用 PNG。

JPG 会为了压缩丢掉细节，所以照片看起来问题不大，但代码截图、UI 截图、二维码这类边缘清晰的内容会明显变糊。PNG 虽然更清晰，但如果拿它保存大幅照片，文件体积会膨胀得很厉害。

PNG vs SVG

PNG 是像素图，SVG 是矢量图。

同一个 Logo，如果用 PNG，放大后会模糊；如果用 SVG，放多大都清晰。因此网站图标、Logo、架构图、流程图优先 SVG。但如果图像是照片，SVG 就不合适。

GIF vs WebP

GIF 胜在历史悠久和兼容性，WebP 胜在效率和画质。

如果只是做传统表情包，GIF 还能用；如果是网站上的动画素材，WebP 通常体积更小、颜色更好。如果动画较长，最好直接考虑 MP4、WebM 这类视频格式。

WebP vs AVIF

WebP 更像“稳妥的现代格式”，AVIF 更像“压缩率更强的新格式”。

WebP 编解码速度和生态成熟度更均衡，适合大多数网站。AVIF 在体积和画质上很有优势，但编码速度、老旧环境兼容、工具链支持都要额外确认。实际项目里经常会用“AVIF 优先，WebP/JPG 兜底”的方式。

HEIC vs JPG

HEIC 更适合手机内部存储，JPG 更适合跨平台分享。

如果照片只是存在手机相册里，HEIC 可以节省空间；如果要上传网站、发给不同设备的人、放进文档或博客，转成 JPG 或 WebP 往往更省心。

五、实际应该怎么选？

使用场景	推荐格式	原因
博客封面、摄影图	JPG / WebP / AVIF	照片类内容需要控制体积
网页截图、代码截图	PNG / WebP 无损	保持文字和线条清晰
Logo、图标、流程图	SVG	可缩放、清晰、体积小
透明背景贴图	PNG / WebP	支持透明通道
简单动图表情	GIF / WebP	GIF 兼容强，WebP 更省体积
长动画或视频片段	MP4 / WebM	比 GIF 更高效
手机照片归档	HEIC / JPG	HEIC 省空间，JPG 更通用
扫描件、印刷交付	TIFF / PNG	保真度高
摄影后期源文件	RAW / DNG	保留最大调整空间

如果只记一套日常规则，可以这样选：

照片用 JPG/WebP，追求极致压缩可考虑 AVIF
截图、二维码、透明图用 PNG
Logo、图标、示意图用 SVG
动图尽量用 WebP 或视频，GIF 只做兼容选择
专业后期保留 RAW/TIFF，发布时再导出成 WebP/JPG

六、常见误区

误区一：PNG 一定比 JPG 清晰

不完全对。PNG 是无损，所以它不会额外破坏像素；但如果原图本来就是低分辨率，存成 PNG 也不会凭空变清晰。

误区二：文件越大画质越好

也不一定。体积大可能只是格式不合适。例如一张照片用 PNG 保存会很大，但视觉效果未必比高质量 JPG 或 WebP 好。

误区三：SVG 一定很安全

SVG 是文本格式，理论上可以包含脚本、外链等内容。自己写的 SVG 问题不大，但用户上传或来源不明的 SVG 不能随便内联到页面里。

误区四：GIF 是做动画的最佳格式

GIF 只是最老、最通用的动图格式，不代表最高效。现在网页动画通常可以优先考虑 WebP、APNG、MP4 或 WebM。

七、总结

图片格式没有绝对的“最好”，只有是否适合当前场景。

JPG 适合照片，PNG 适合清晰截图和透明素材，GIF 适合简单兼容动图，WebP 和 AVIF 适合现代网页优化，SVG 适合图标和示意图，HEIC 适合手机存储，TIFF 和 RAW 更偏专业生产链路，BMP 则更多是历史和兼容场景。

真正的选择逻辑可以浓缩成一句话：

看内容类型选格式：照片看压缩，截图看清晰，图标看矢量，动画看时长，专业素材看后期空间。

HTTP 和 HTTPS 的区别：从明文到加密，一篇讲清楚

Mon, 10 Aug 2026 21:40:29 +0800

HTTP 和 HTTPS 的区别：从明文到加密，一篇讲清楚

HTTP 和 HTTPS 的核心区别不是“能不能打开网页”，而是：网页数据在网络上传输时，是否有加密、身份认证和完整性保护。

一句话先记住：

HTTPS = HTTP + TLS。

也就是说，HTTPS 并没有推翻 HTTP 的请求方法、状态码、Header、Cookie、缓存这些机制。它是在 HTTP 通信外面加了一层 TLS 安全通道，让浏览器和服务器先建立可信、加密的连接，然后再传 HTTP 数据。

先看最直接的区别

对比项	HTTP	HTTPS
URL 前缀	`http://`	`https://`
默认端口	80	443
传输内容	明文	经过 TLS 加密
身份认证	无法证明服务器真实身份	通过证书证明服务器身份
完整性保护	容易被中间人篡改	篡改会被发现
浏览器提示	常显示“不安全”	显示安全连接标识
适合场景	本地开发、临时内网测试	生产网站、登录、支付、接口、后台系统

很多初学者会把 HTTPS 理解成“高级版 HTTP”。这个说法不算错，但更准确的理解是：HTTP 负责表达网页请求和响应，TLS 负责保护这段通信过程。

HTTP 做了什么

HTTP，全称是 HyperText Transfer Protocol，超文本传输协议。它定义了浏览器和服务器之间如何对话。

例如你访问一个页面时，浏览器可能会发出这样的请求：

GET /articles/http-vs-https HTTP/1.1
Host: example.com
User-Agent: Chrome
Accept: text/html

服务器再返回：

HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <body>Hello HTTPS</body>
</html>

这套格式本身没有问题。HTTP 的价值在于简单、通用、可扩展，Web 上的请求方法、状态码、Header、Cookie、缓存控制，都是它的核心组成部分。

问题在于：如果只使用 HTTP，这些内容会以明文形式经过网络。

明文传输为什么危险

假设你在咖啡店 Wi-Fi 下登录一个只支持 HTTP 的网站，你输入的用户名、Cookie、请求路径和响应内容，都可能被同一网络里的攻击者看到。如果攻击者进一步做中间人攻击，还可能把服务器返回给你的页面内容替换掉。

HTTP 明文带来的典型风险有三个：

风险	含义	例子
窃听	第三方可以读到传输内容	看到登录表单、Cookie、接口返回
篡改	第三方可以修改传输内容	注入广告、替换下载链接、改写脚本
冒充	用户无法确认对面是不是真服务器	被引导到伪造服务器却不容易察觉

所以，HTTP 最大的问题不是“协议设计得不好”，而是它默认不解决安全传输问题。

HTTPS 加上的 TLS 是什么

TLS，全称是 Transport Layer Security，传输层安全协议。HTTPS 使用 TLS 在浏览器和服务器之间建立安全通道。

TLS 主要提供三件事：

能力	解决的问题	可以怎么理解
加密	防止第三方看懂内容	即使抓到数据包，也只能看到密文
身份认证	防止连到假服务器	浏览器会检查服务器证书是否可信
完整性校验	防止内容被偷偷改掉	数据一旦被篡改，校验会失败

因此，HTTPS 传的仍然是 HTTP 请求和响应，只是这些 HTTP 数据会先被 TLS 加密，再放到网络里传输。

TLS 握手大致怎么发生

在浏览器真正发送 HTTP 请求之前，HTTPS 会先进行 TLS 握手。握手的目的不是传业务数据，而是完成几件关键准备：

双方确认使用哪个 TLS 版本和加密算法。
浏览器验证服务器证书。
浏览器和服务器协商出后续通信使用的会话密钥。
握手完成后，HTTP 请求和响应都走加密通道。

可以把这个过程理解成：

两个人先确认对方身份，再商量一个只有双方知道的临时密码。之后真正聊天时，所有内容都用这个临时密码加密。

现代 HTTPS 通常使用 TLS 1.2 或 TLS 1.3。TLS 1.3 对握手流程做了简化，配合会话恢复、HTTP/2、HTTP/3 和 CDN，HTTPS 的性能成本已经远小于早期印象里的“很慢”。

证书到底证明了什么

很多人看到浏览器地址栏里的安全标识，会下意识理解成“这个网站一定是好网站”。这其实是误解。

HTTPS 证书主要证明的是：

你当前连接到的服务器，确实拥有这个域名对应证书中的私钥，并且这个证书能沿着可信 CA 链被浏览器验证。

它不保证网站内容一定真实、商家一定可靠、业务一定没有漏洞。钓鱼网站同样可以申请 HTTPS 证书，所以 HTTPS 只能说明“连接安全”，不能说明“网站本身可信”。

浏览器通常会检查这些内容：

检查项	为什么重要
域名是否匹配	`example.com` 的证书不能拿去冒充 `bank.com`
证书是否过期	过期证书不应继续被信任
签名链是否可信	证书需要能追溯到浏览器信任的根 CA
证书是否被吊销	泄露或失效的证书应被拒绝

通过这些检查后，浏览器才会继续完成 TLS 握手，并把连接标记为安全。

HTTP 和 HTTPS 的关键差异

从开发和运维角度看，最值得关注的是下面这些差异。

维度	HTTP	HTTPS
安全性	无加密、无认证、无完整性保护	有加密、认证和完整性保护
请求格式	HTTP 方法、Header、Body	逻辑上仍是 HTTP 方法、Header、Body
传输层	通常直接跑在 TCP 上	HTTP 先进入 TLS，再跑在 TCP 或 QUIC 上
证书	不需要证书	需要有效 TLS 证书
端口	默认 80	默认 443
SEO 和浏览器策略	搜索和浏览器体验不友好	更符合现代 Web 默认要求
Web 能力	一些能力受限	Service Worker、地理位置、剪贴板等能力通常要求安全上下文
迁移成本	配置简单	需要证书、跳转、混合内容修复和监控

这里有一个容易忽略的点：HTTPS 不会改变 HTTP 的语义。

GET 还是 GET，POST 还是 POST，404 还是 404，Cookie 还是 Cookie。它改变的是这些数据穿过网络时的保护方式。

HTTPS 会不会更慢

早期 HTTPS 的确会带来明显额外开销，因为 TLS 握手需要额外往返，还要做加解密。但今天不能简单地说“HTTPS 一定慢”。

原因主要有几个：

TLS 1.3 减少了握手成本：建立连接需要的往返次数更少。
会话恢复可以复用安全参数：老用户再次访问时不必完整握手。
HTTP/2 和 HTTP/3 改善了传输效率：多路复用减少了大量小请求的阻塞。
硬件和软件加密性能已经很高：常见服务器处理 TLS 的成本通常不是主要瓶颈。
CDN 可以承担 TLS 终止：证书、握手和边缘节点优化可以由 CDN 处理。

更实际的结论是：

对现代生产网站来说，HTTPS 的安全收益远大于额外成本。性能优化应该建立在 HTTPS 之上，而不是为了省一点握手成本退回 HTTP。

HTTPS 能保护什么，保护不了什么

HTTPS 很重要，但不要把它当成万能安全方案。

问题	HTTPS 能否解决	说明
第三方读取请求路径、Cookie、请求体	能	这些内容会被 TLS 加密
第三方篡改页面、脚本、接口响应	能	篡改通常会导致校验失败
证明服务器身份	能	前提是证书链和域名校验通过
隐藏访问的网站 IP	不能	IP 层仍需要知道连接到哪里
完全隐藏访问域名	不一定	DNS、SNI 等环节在不同配置下可能暴露域名信息
防止网站自身泄露数据	不能	服务端漏洞、日志泄露、数据库泄露仍需单独治理
防止用户访问钓鱼网站	不能完全防止	钓鱼网站也可以有 HTTPS 证书

因此，HTTPS 是 Web 安全的地基，但不是整栋楼。登录鉴权、权限控制、输入校验、XSS 防护、CSRF 防护、日志脱敏、密钥管理，这些仍然要单独做好。

从 HTTP 迁移到 HTTPS

给网站加 HTTPS，不只是把证书装上去。生产环境里，最常见的问题反而出在跳转、混合内容和缓存策略上。

一个比较稳妥的迁移清单如下：

步骤	要做什么	常见坑
申请证书	使用 Let’s Encrypt、云厂商证书或企业 CA	忘记配置自动续期
配置 HTTPS 站点	监听 443，并绑定证书和私钥	证书链不完整
HTTP 跳转 HTTPS	80 端口统一 301 到 443	跳转循环、代理头配置错误
修复混合内容	页面里的图片、脚本、接口都改成 HTTPS	浏览器拦截 `http://` 脚本和接口
设置 Cookie 属性	登录 Cookie 加 `Secure`、`HttpOnly`、`SameSite`	HTTPS 下 Cookie 策略不一致
谨慎开启 HSTS	确认全站和子域名都支持 HTTPS 后再开启	一旦配置过猛，回滚会很麻烦
更新外部入口	CDN、反向代理、站点地图、canonical、监控	搜索引擎和监控还在访问旧地址

Nginx 里一个非常简化的跳转配置类似这样：

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass http://app;
    }
}

真实线上配置还要结合负载均衡、CDN 回源、证书续期、日志、监控、灰度和回滚策略一起看。

常见误区

误区一：HTTPS 网站一定安全。

不对。HTTPS 只能说明连接被加密且证书校验通过，网站是否有漏洞、业务是否可信，是另一回事。

误区二：有 HTTPS 就不会泄露任何信息。

不对。HTTPS 保护的是应用层内容，但 IP 地址、流量大小、访问时间等元数据仍可能被观察到。域名是否暴露还取决于 DNS、SNI、ECH、代理等具体配置。

误区三：接口在内网就不用 HTTPS。

不一定。内网也可能有越权访问、旁路抓包、错误代理、日志泄露等风险。涉及账号、Token、用户数据、后台管理的接口，即使在内网也建议使用 HTTPS 或等价的传输层保护。

误区四：HTTPS 配好一次就结束。

不对。证书会过期，TLS 配置会老化，依赖的加密套件也可能不再推荐。证书续期、过期告警和安全扫描都应该纳入运维流程。

总结

HTTP 和 HTTPS 的关系可以用三句话收束：

HTTP 负责“怎么表达请求和响应”，例如方法、状态码、Header、Body。
HTTPS 负责“安全地传这些 HTTP 数据”，核心靠 TLS 提供加密、认证和完整性保护。
生产环境默认应该使用 HTTPS，HTTP 最多作为跳转入口，或者用于受控的本地开发和临时测试。

所以，下次再看到 http:// 和 https://，不要只把它们当成 URL 前缀的差异。真正的区别在于：你的数据是裸奔在网络里，还是走在一条经过身份校验和加密保护的通道里。